Extending the Desktop Entry spec for static app actions
scampa.giovanni at gmail.com
Mon Nov 28 11:02:09 PST 2011
Il giorno lun, 28/11/2011 alle 12.29 -0500, Matthias Clasen ha scritto:
> On Thu, 2011-11-24 at 17:41 +0100, Giovanni Campagna wrote:
> > 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.
> desktop-file-validate will not accept this as is anyway, since the group
> name doesn't start with an X-. Which is the main beef I have with
> Canonical pushing these desktop entry extensions without seeking
desktop-file-validate will accept it, once this is a freedesktop
standard. And if not, it becomes a bug we can fix.
> I don't think adding 'Shortcut Group' to the group name adds anything,
> really, and I'd prefer to just use the identifier unchanged. Also,
> DesktopShortcuts could be shortened to just 'Shortcuts' without any
Adding "Shortcut Group" allows us to add other stuff in the future,
without breaking desktop file that may exist at that time, with weird
As for DesktopShortcuts, I'm not sold to it. Some one proposed Actions
earlier: what about that?
> > Any opinions or comments? If not, I'll prepare a patch for the
> > specification.
> I think the main thing missing here is motivation and expectations. The
> spec needs to explain what implementations are supposed to do with these
> shortcuts. E.g. is it ok to just ignore them ?
My original mail was not meant to include all and only the new spec
text, but I would go with this:
Desktop entries of type Application can optionally include one or more
shortcut groups [actions]. This represent additional ways to invoke the
particular application; it is expected that application launchers will
expose them in some way (for example, as a submenu) within the context
of the application, to build so called "Quicklists" or "Jumplists".
It is still perfectly legal for any consumer of this specification to
ignore secondary actions, so the primary way to invoke the application
should be through the main Exec line, as well as the primary Name and
Also, it is not expected that other desktop components showing app lists
(such as, software installers or file type settings) will provide any UI
for these actions, therefore applications should only include actions
that make sense as general launchers.
Finally, no provision is made to check that the application is actually
running when these additional actions are invoked or shown.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part
More information about the xdg