As part of GNOME 3.4, we expect to provide the applications with the ability to install custom actions within their own app launcher. This is something Unity has done since the first release, therefore I think it would be useful to agree on a common format, so that multiple environments could benefit from this feature.
As a starting point, the Unity implementation of this is documented to work as following: One key X-Ayatana-Desktop-Shortcuts (type string list) with a list of identifiers. One group for each shortcut, with name "<identifier> Shortcut Group". Each group has Name (type localestring), Exec (type string), TargetEnvironment (which must be the exact string "Unity"). Clearly, as we're moving this to freedesktop, we can remove the X-Ayatana prefix, clean up TargetEnvironment and add some missing but useful keys to shortcuts, so the resulting format would be: [Desktop Entry] .... DesktopShortcuts=(string list) [Shortcut Group %s] Name=(localestring, req) Icon=(string, opt) Exec=(string, req) OnlyShowIn=(string list, opt) NotShowIn=(string list, opt) Identifiers must be composed only of lowercase alphabetic characters from the ASCII set, plus underscore and minus. Some implementations may give special meanings to some identifiers (for example, replacing a default new window action with a shortcut idenfied by new-window), though this is not required. The group name is reversed, to ensure we always start with a known string. This is an assumption desktop-file-validate currently makes, and is good in general. Name is the label that will be shown to the user. There is no provision for Comment or GenericName, as it is expected that this is always shown in the context of a specific application (that is, as a submenu of a launcher) and therefore only need to be unambiguous within one app. Exec is to be interpreted as [Desktop Entry]\Exec, including macro expansion and PATH resolution. There is no TryExec, as I expect that a faulty installation affects not only this secondary executable but also the primary ([Desktop Entry]\TryExec) one. OnlyShowIn/NotShowIn have the usual meaning, except that they only refer to a specific launcher. Clearly, OnlyShowIn/NotShowIn for the whole app affect also all launchers. Other properties that could be added are Terminal, Path, MimeType, StartupNotify and StartupWMClass, although I'm not sure of their utility. In any case, if missing, their value is taken from the [Desktop Entry] group. Any opinions or comments? If not, I'll prepare a patch for the specification. Thanks, Giovanni _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg