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

[Matthias Klumpp]

2017-03-15 13:41 GMT+01:00 Simon McVittie <simon.mcvittie at collabora.co.uk>:
> 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?

Sounds very similar at least. Why don't you use the component-type to
determine whether something is an "app" or not? By definition,
type="desktop-application" apps *must* be launchable, while
generic-type components or e.g. type="font" components don't need to
be launchable or can't be launchable.

> 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 :-)

Ditto, I dislike it too. My current definition is roughly "some
launchable program the user can interact with".

>> 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?

Good question. The thing is, we already cover 90% of the desktop-entry
spec (name, summary, mimetypes, icons, etc.), so, by adding the last
remaining bits we enable people to generate a compatible .desktop file
directly from their metainfo file, thereby making it unnecessary for
them to write another file with almost the same metadata.
This means less work for people who want to use this feature.

> 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.

Nice! AFAIk DBus-activation based solely on .desktop files isn't a
thing yet, but maybe it should be? Are there any plans to move this
upstream and add code to DBus itself to directly launch stuff from
.desktop files (avoiding the need to generate another file from them)?

>> 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?

Not initially, but I think by now there is quite some merit to it, to
avoid having people write the same data twice. This would *only* apply
to projects where the metainfo file is equivalent to one .desktop file
though, other projects would still need to write separate .desktop
files.
But since most of the time a metainfo file maps to a .desktop file,
allowing people to have all their metadata in one place and
auto-generate special files from it makes a lot of sense to me.

> 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?

Jup - and this would already be solved by the "simple" proposal - the
more complex version is in there to make the metainfo file more
versatile and allow to generate a full .desktop file from it and
allowing easy future expansion. But the actual problems would be
solved by adding either of the solutions.

> (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.)

Jup. The additional <actions/> stuff in metainfo files might therefore
be metainfo-file only and not end up in collection metadata - unless
we find out that users might actually be interested in information
about what context actions and app provides prior to installing it :P

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/