[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: adding desktop files to misc packages

On Fri, Jul 13, 2007 at 10:10:09PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > We can use additional keywords in the desktop entries to get them sorted
> > in sub-menus when appropriate, but many desktop files are not tagged
> > correctly. As you can see in the specification [0], all categories we
> > need should be here, so if we tag desktop files appropriately, the
> > generated menu should be usable.
> Oddly, the specification nearly exactly mirrors the despised
> Debian menu system, as far as the categorisation of games goes:


Just a few thoughts based on my personal experience. I present you my home
system: sid, GNOME 2.18, but not with the full gnome-desktop-environment
metapackage installed, as it's rather huge, but with gnome-core and an
assorted collection of gnome-specific packages as well as many games.

In my case the Debian menu properly introduces these games in their proper
submenu but the GNOME menu does *not* create submenu for any of the
categories, all games are presented in a flat menu which overflows the
screen. Is this a feature only available when installing a particular

Check this:
$ find . -name "*desktop" -exec egrep "Categories.*Game.*" \{\} \;  | wc -l

I get all these 54 items in GNOME's Game menu with no category division. 
And, both GNOME *and* KDE *and* Desktop-agnostic games are shown there. 

Not that I'm completely in favour of submenus (a submenu with a single entry
does not seem useful to me). However, having a list of items that cannot be
seen on screen without browsing through it does not seem very user-friendly
to me. Specially as I don't play all games often (just a few of them)

What I would like to see implement (in the UI side?=
update-menus could also):

a- if # items in a menu are < THRESHOLD then present them in a flat list
b- if # items in a menu are > THRESHOLD then use submenus to categorise
    but, if there is a submenu that has < THRESHOLD_B items (say 1) then
    do not create a submenu for it.
c- "learn" which items the user uses most and present those hiding others
  (there's people which despise this feature from other OSes, I actually
   find it useful)

This could be implemented in the UI side, but maybe update-menus could
also implement this (specially a and b) to prevent having submenus with just
1 item.

I don't see any of this being mentioned in GNOME's Menu Usability wiki
(http://live.gnome.org/UsabilityTeam/Menu) which seems to imply that a flat
hierarchy is prefered by GNOME (but it is quite useless in Debian, as we do
carry much more applications if you install both GNOME and KDE). But maybe it
is because it works (better) in other (heavier) GNOME environments.

BTW. If I use GNOME's built-in menu editor (the one you get when you
right-clink on the footprint with just gnome-panel installed, not alacarte,
as it is not installed) I'm not able to create submenus and, even, to see the
categories the different desktop files assign to each Game. That isn't too
user-friendly to me.

I know I can install alacarte (pulled in by gnome-desktop-environment) but
IMHO a *proper menu editor should be an essential part of the GNOME desktop.
However, even if I install alacarte I don't get the option to create
submenus automatically based on the Game categories (which, again, are not
shown). Which means I have to automatically sort games byhand into menus when
there is already information in the desktop files to do this!

Just my 2c,


Attachment: signature.asc
Description: Digital signature

Reply to: