This will be a DEP some day, but let's focus on Squeeze first.
Desktop entry specification: http://standards.freedesktop.org/desktop-entry-spec/latest/
Menu entry specification: http://www.debian.org/doc/packaging-manuals/menu.html/
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 |
|
|
icon16 |
? Icon? |
The desktop standard appears to only allow a single icon |
|
icon32 |
? Icon? |
The desktop standard appears to only allow a single icon |
|
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). |
Suggested Field |
Rationale' |
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? |
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.