Extending the Desktop Entry spec for static app actions

Ted Gould ted at gould.cx
Mon Nov 28 16:15:13 PST 2011


First, thanks for proposing this!  I hadn't realized that this was going
forward on the GNOME side.  I'm very excited to get this out of the X-
namespace.

Second, I don't have a strong opinion on the naming and we can change
the naming used in Unity to match what people are comfortable with.

Lastly, I'd be happy to help with spec and/or tool patches.

		--Ted


On Thu, 2011-11-24 at 17:41 +0100, Giovanni Campagna wrote:
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20111128/3db22985/attachment.pgp>


More information about the xdg mailing list