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

[Matthias Klumpp]

Hi!
This was already briefly discussed on IRC about a month ago, and I so
far didn't have time to summarize this new tag on the ML. Since I want
something like this in the upcoming release of AppStream though, it's
time to bring it up here to get some feedback.

= The Problems =

At time, for desktop-application metainfo files, their component-id is
tied to the .desktop filename. So if your application's .desktop
filename is called org.example.foobar.desktop, the component-ID of the
accompanying metadata *must* be "org.example.foobar.desktop" or
"org.example.foobar".

This leads to annyoing problems. First, there are some application
suites which always install multiple apps together and therefore have
multiple .desktop files. For these, it isn't clear which .desktop file
should be the prime file for representing the application in its
metainfo file. Ideally the metainfo file should be standalone and not
be tied to a .desktop file, but AppStream doesn't explicitly allow
that yet (or rather, AppStream clients don't expect that).

Additionally, there are projects like Wine which don't have a single
launchable .desktop file, but can be considered desktop-apps in a
wider sense and make sense to be installed from tools like GNOME
Software.
At time, Wine has a standalone metainfo file in Debian, breaking GNOME
Software's assumption to use the cID as launchable .desktop file
(therefore showing a broken launch button). Launching desktop-apps via
the cID is also not always working already, especially for apps from
the KDE4-era, since a .desktop file is != a desktop-id, which is the
actual thing needed to launch an app.

The third issue is renaming of .desktop files. As soon as a .desktop
file name changes, the metainfo file must change as well, breaking the
globally unique component-ID and e.g. making appstream:// URLs fail
and breaking software relying on a fixed name (fortunately, that's a
really rare issue).
Also, many .desktop files not being converted to the reverse-DNS
scheme and people not wanting to rename .desktop files for good
reasons prevents us from enforcing proper component-IDs for the
desktop-app component type.

= Proposed Solution =

Having additional meaning other than "unique name for the given
software component" tied to the cID is a speciality of the
desktop-application component type, and it's a thing I consider a flaw
in the specification and something which isn't a great idea anymore.
So we should get rid of that. At the same time, we still need metainfo
files to be able to link to .desktop files so tools like GNOME
Software know how to launch stuff, and metadata generators can fetch
additional information from .desktop files.

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 "desktop-id" would be the only supported launchable type
initially, the others could follow.
Having this would solve all problems outlined above, but when
specifying multiple launchable items per component, the user would
have no clue about what the individual commands are for.

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:

```
<launchable type="default" id="run-main-app>
    <name>Run application</name>
    <exec type="desktop_id">org.example.foobar.desktop</exec>
    <exec type="command">/usr/bin/foobar %H</exec>
    <action id="capture-screen">
        <name>Run in screen capture mode</name>
        <exec type="command">/usr/bin/foobar --capture</exec>
    </action>
</launchable>
<launchable id="run-app-config>
    <name>Configure foobar</name>
    <exec type="desktop_id">org.example.foobar-configure.desktop</exec>
    <exec type="command">/usr/bin/foobar-config</exec>
</launchable>
```

This would reflect the run actions / jumplist stuff in .desktop files
too. I don't know if it needs to be that detailed, but I want to have
some solution to the issues.
I am very interested in your opinion! Nothing is set in stone yet (not
even the name, but I haven't found any better term than "launchable"
to describe what this does yet).

Cheers,
    Matthias

--
I welcome VSRE emails. See http://vsre.info/