Extending the Desktop Entry spec for static app actions

[Giovanni Campagna]

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