[AppStream] Introduction of "launchable" tag for metainfo files

[Simon McVittie]

On Wed, 15 Mar 2017 at 13:21:41 +0100, Matthias Klumpp wrote:
> I therefore want to add a generic "launchable" tag to the
> metainfo/collection spec. It would look like this:
> 
> ```
> <launchable type="desktop-id">org.example.foobar.desktop</launchable>
> <launchable type="dbus">org.example.foobar.Run</launchable>
> <launchable type="command">/usr/bin/foobar %H</launchable>
> ```

The embedded (automotive) operating system I'm currently working on uses
AppStream as a basis for an "app store". We make a distinction between
"app-bundles" (installable things with AppStream metadata) and
"entry points" (things you can launch from a menu entry or a media type
or URI scheme association, represented by .desktop files;
the name is partly inspired by the Desktop Entry specification).

Each app-bundle has 0 or more entry points. It might have no entry
points at all if it isn't actually executable code (for instance
if there are user-installable themes), or it might have more than one
if it contains multiple menu entries (a common example on desktop is
LibreOffice).

Your launchables are exactly our entry points, I think?

We're trying to avoid using "app" as a jargon term altogether, because
it has so many subly different meanings, many of which are the same 90%
of the time and only differ in exactly the difficult cases where jargon
terms are needed for disambiguation :-)

> The "desktop-id" would be the only supported launchable type
> initially, the others could follow.

I'm a little curious why you want to cover all the possibilities:
we already have a freedesktop.org specification for "user-launchable
things" (it's the .desktop file). Would it be better to just mandate
that desktop files are used?

At the moment I'm actually working on code to generate transient
systemd user services and D-Bus session services from DBusActivatable
.desktop files (using vendor-specific extension fields in the .desktop
file for now, until we have some implementation experience), so that
app-bundles only need to contain a .desktop file, and it will
automatically gain auto-activation support if implemented.

> So, there is also a more complicated layout proposal for this, which
> we could use instead of the above, and which would - given enough
> metadata - ultimately allow us to even generate .desktop files from
> metainfo files

I didn't think duplicating all of the Desktop Entry specification
was something AppStream wanted to do?

Stepping back from this a bit, is the use-case for this that GNOME
Software wants to launch an installed AppStream component? If so, is
the problem really mainly that GNOME Software can't necessarily know
which installed .desktop file corresponds to which installed AppStream
component in a general way?

(If it had that information, it could have 0 or more launch buttons, one
per desktop file, and the problem would be solved; it can't usefully have
launch buttons for software that isn't installed yet anyway.)

    S