Proposal: using Desktop entries with the Debian menu system

Parallel between Menu and Desktop entries

NOTE: the Desktop entry file is UTF-8, while the Debian Menu entry specification, section 3.2, insists on the use of an ASCII (7 bit) character set to support older window managers. This means that fields from a Desktop file can not simply be used to generate Menu files without checking for non-ASCII characters.

Desktop entries have a format similar to ".ini" files. Menu entries have their own format. But both have a set of "keys" (Desktop) or "fields" (Menu) that are mostly overlapping:

Menu entry field

Corrseponding Desktop entry key

Comment

title

Name

Desktop entries also provide ?GenericName

longname

Comment

This (depending on configuration) may be mouseover-text or substitute title, and the desktop spec says that Comment is the tooltip value

needs:x11

Terminal=false

Optional: default is false

needs:terminal

Terminal=true

needs:wm

missing

Could be emulated by X-Debian-needs=wm, as Debian would be upstream of these entries anyway. Seems like something that should be a Category, though.

needs:vc

missing

Could be emulated by X-Debian-needs=vc, as Debian would be upstream of these entries anyway. Maybe use ?OnlyShowIn?

section

Category

Menu sections correspond to "Main" Desktop categories

command

Exec

icon

Icon

Desktop files only specify the base icon name, e.g. Icon=$appname. The DE is then supposed to look for a suitable icon first in the current icon theme (if available), then as a fallback in the hicolor icon theme.
In most cases, icons should therefore be installed at:
/usr/share/icons/hicolor/$size/apps/$appname.png
where $size is normally one of 16x16, 22x22, 32x32, 48x48, 64x64, 128x128, and $appname matches the key in the Desktop file.

icon16

icon32

hints

Category

Hints correspond to "Additional" Desktop categories, but only a finite set is allowed.

package

missing

Used to identify whether the item should be installed in the menus at all. Is this required if the menu file is always uninstalled with the application? We may be able to take care of this by requiring the desktop file be included in the same package as the application (not in, for instance, a separate data package that could be installed when the application isn't). Files that are separate to the application can use ?TryExec.

Suggested Field

Rationale'

?HideIn

?OnlyShowIn becomes cumbersome when we're trying to exclude one or two desktops rather than only include a specific one or two. E.g. gcalctool is currently ?OnlyShowIn=GNOME;XFCE;LXDE; but that's because it doesn't belong in KDE's menu, but otherwise is fine. It should be ?HideIn=KDE;

?HideInMenu(?)

This key (or something like it) is used by GNOME that that programs GNOME maintainers don't think are good enough to show up in the GNOME menus don't unless you manually edit the menu. (It doesn't appear in the menu, but the menu editor will allow to to override the default and select it as shown). Isn't this just Hidden?

Possible issues

An alternative would be to migrate away from debian .menu files and use .desktop files instead. This was done by Mandriva, and their migration effort is documented on http://wiki.mandriva.com/en/Development/Howto/MenuMigrationToXDG .

Comments

Comment from ?PetterReinholdtsen: What about using a Category for needs:vc? Perhaps add ?VirtualConsole to Categories. It will allow those interested to filter in or out the relevant entries. According to http://lists.debian.org/debian-devel/2007/08/msg00158.html there are 27 packages using this value.