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

[Matthias Klumpp]

Okay, after some IRC discussion with Richard we settled on using
"launch" as tag name and don't implement the full desktop stuff yet
(which wasn't the plan anyway...), but maybe add that at some point in
the future if it should be necessary.
Until then, we'd keep the spec simple.
So, the new tag will look like this:

<launch type="desktop-id">org.example.Test.desktop</launch>

The value is a desktop-id as described in [1]. At least for AppStream
0.11 I won't add another launch type. The type property won't be
optional, so we will not implicitly assume a desktop-id in case the
type isn't specified (as done with other tags like <component/>
iitself).

I will change the spec so that desktop-application components with a
<launch> tag don't have to have a .desktop suffix and must follow the
reverse-DNS spec. If a desktop-app doesn't have a launch tag, it's ID
must match the .desktop file.
I would like to gradually phase out desktop-application having no
<launch/> tag, so adding this tag is highly recommended (it can't be
required yet, at least not by AppStream implementations, because that
would render many existing metainfo files invalid and cause
confusion).

I will update the specification soonish, and add some compatibility
glue to libappstream. The appstream-generator tool will likely return
the <launch/> tag for every desktop-applicatioon soon, as we can
easily generate it from the component-ID in case the tag is missing,
so frontends can rely on the tag's presence a bit more.

All in all, I expect no breakage by this change at all :-)

If there are any objections / suggestions /comments especially to the
tag name and definition, please let me know!

Cheers,
    Matthias

[1]: https://standards.freedesktop.org/desktop-entry-spec/latest/ape.html

2017-03-17 17:29 GMT+01:00 Matthias Klumpp <matthias at tenstral.net>:
> 2017-03-17 16:44 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
>> On 15 March 2017 at 12:21, Matthias Klumpp <matthias at tenstral.net> 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>
>>
>> Like, although I'm not convinced about the 'launchable' name (although
>> can't immediately come up with an alternative).
>
> I am not super-happy with it either, but I couldn't come up with any
> real alternative (except "launch", which is meh)
>
>>> <launchable type="dbus">org.example.foobar.Run</launchable>
>>
>> Not like. What parameters are we supposed to call that method with?
>> I'm sure the desktop would want to pass at least the timestamp to do
>> focus-stealing prevention.
>
> Since a standardized interface already exists[1], I think we would
> even only need to set the interface name here...
>
> [1]: https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
>
>>> <launchable type="command">/usr/bin/foobar %H</launchable>
>>
>> What does %H mean in the context of a software center?
>
> I guess it should just ignore it. As per[2], %H doesn't even exist,
> for some reason in my mind this was for "multiple files" :P
>
> [2[: https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables
>
>>> 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 don't like this and moves the metainfo file away from "something for
>> the software center" to "jack of all trades metadata".
>
> You pretty much did that already by adding tons of stuff and even a
> dependency logic to your firmware-specific metainfo files ;-)
> What I am thinking here is "why have the developer write multiple
> metadata files while you can generate one from the other at
> compile-time"?
>
> Cheers,
>     Matthias
>
> --
> Debian Developer | Freedesktop-Developer
> I welcome VSRE emails. See http://vsre.info/



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