Differences between revisions 15 and 16
Revision 15 as of 2013-09-29 22:39:40
Size: 5729
Comment: Removed obsolete head comment, added title and subtitles.
Revision 16 as of 2013-09-30 20:56:27
Size: 6047
Editor: DanielPocock
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:

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.

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

  • There needs to be an agreed upon set of Categories for Categories=. Currently there are somewhat overlapping but disjoint sets of category names used by different desktops and packages. There is a standard for this: http://standards.freedesktop.org/menu-spec/latest/

  • What is to be done about desktop-specific keys
  • Need to list what keys are actually used by easy DE (as different desktops have different keys and use some keys on different ways). For instance, KDE has a ton of extra keys and GNOME and KDE don't necessarily agree on usage. KDE 4 may be moving closer to converging on a shared standard.
  • Some desktop maintainers don't want all packages to show up in 'their' desktop menus and want to control what packages are actually listed on the menus. What do you do about that, and how to you make sure that all packages have some means of being shown if the user actually wants to see them?
  • How do we validate and syntax-check desktop files? Lintian currently does its own parsing and validation based vaguely on the standard, but there are a lot of weaknesses. Is desktop-file-validate from desktop-utils reliable and maintained upstream for this purpose?
  • Desktop files support translation. We should have a plan in advance for how to incorporate this into existing Debian translation processes.
  • The supporting programs provided by the current menus package used by window managers and friends to generate menus would need to be supported for desktop files, or some equivalent provided.

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.