Re: (Possible) menu code rewrite
On Jul 16, Joseph Carter wrote:
> I've got a concern which I've raised before, however, about things which
> the Debian menu supports which are not found in Gnome or KDE. Primarily
> of interest are that console-only applications are not supported, and
> neither are menu hints. I can live without the latter if we coordinate
> things sanely so that the menus do not get overly large as they do
> currently with a million things in /Apps/Net and /Apps/Tools. The former
> can be handled by adding an X-Debian-ConsoleOnly key to the .desktop
> format, but if we do this we need to patch everything that currently uses
> .desktop files (Gnome and KDE primarily) to support them.
> A better suggestion would be to coordinate this effort with the xdg list
> and make a ConsoleOnly key standard. I'm told the xdg guys will be much
> more inclined to consider such a thing knowing that Debian wants to use
> the .desktop files for distribution-wide menus..
I agree we need to figure out something that will accomodate all of
the existing functionality. I'm signing up for xdg-list and will
review the .desktop entry specification at
> I've got one other suggestion for addition to the format, really. More
> useful than a hint about where to put a menu entry is whether or not you
> should show it at all, based on the sort of user you're dealing with. A
> user who is very technically astute would probably find it useful having
> the Gnome calculator sitting there in the menu right next to entries which
> run bc or dc in a terminal window.. My mom would not, however. This is a
> problem with the Debian menus, and even to some extent an upstream Gnome
> and KDE problem - both desktops have tools which are not for the unwashed
> masses who don't know what they do.
Yes, though I'm not sure how this should be handled.
> Regarding compatibility with old menu files and methods, suggest you read
> the old files when a .desktop is not available. Get the .desktop
> formalised into policy and start phasing out the old menu.. This is also
> beneficial for FHS compliance, so it's good to get started soon.
Not sure how this relates to the FHS, exactly...
Chris Lawrence <email@example.com> - http://www.lordsutch.com/chris/
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com