Using appstream in xdg-app

[Matthias Klumpp]

2015-12-18 16:27 GMT+01:00 Richard Hughes <rhughes at redhat.com>:
>> Each app ships an exported appinfo file. It goes into
>> export/share/appdata, similar to how the desktop files goes in
>> export/share/applications.
>
> Makes sense.

Jup, +1

>> The name of the appinfo file needs to be "$(APP_ID).appdata.xml", in
>> order to be allowed for export (xdg-app only allows files with the app-
>> id as prefix to be exported, to avoid conflicts in the exported
>> directories). The id of the app should be that of the desktop file,
>> which due to the prefix rule is "$(APP_ID).desktop", and similarly the
>> icon will have the app-id as the prefix.
>
> Is this an upstream change required for apps? If so we probably want to blog about this a bit more, and if this does stick it makes the "find an application icon" code in appstream-glib becomes SO much simpler.

Well, you can't assume that everyone will follow that guideline if
just because we say so (as always)...

>> In the repo
>> ===========
>> [...]
>> Additionally, during the extraction of the appinfo we can supply
>> custom xml that overrides the appdata from the apps, or supply extra
>> translations.
>
> Any ideas on the format of this?

We could simply add an AppStream distro XML file with higher priority
and have that one override the existing data - same mechanism as we
already use on the clients as well.

>> On the client
>> =============
>>
>> Each xdg-app directory (i.e. /var/xdg-app and ~/.local/share/xdg-app)
>> will maintain a local mirror of the "appdata" branch of each
>> configured remote. This will typically be a reference called
>> "€remotename:appdata/$arch" and be stored in
>> "repo/remotes/$remotename/appdata/$arch".
>
> wfm.
>
>> Additionally, there will be a deployed version of this branch in
>> "appdata/$remotename". This is where e.g. gnome-software would look
>> for appdata info and icons.

Why does this need to be done? If the repository data & icons are
already exported to /var/{lib|cache}/app-info/{xmls|icons}, all
AppStream implementations will read it. With xdg-app putting stuff
elsewhere, there are even more locations to read data from, and if we
can assume the distro XML is up-to-date, we don't nee to read the
AppData stuff at all.

>> Localized data is pretty large, and we generally don't need all
>> locales. For instance, on my fedora 23 install 62% of the uncompressed
>> repo appdata is made up of localized strings. We could split up the
>> xml files per-locale and have separate branches (say
>> "appdata/$arch/$locale" and "appdata/$arch/icons"). Would this be
>> worth it? Also, does appstream support localized icons?
>
> We support localised icons in theory, but I don't think any of the tools support it.

I would say we don't support localized icons at all - it's not
mentioned anywhere in the spec, and if we would support localizations,
we would need to define subdirectories for localization in the icon
cache or have the icon files renamed to something, which is completely
unclear. Also, no tool will understand localized icons currently, and
I've see no application using them, likely because the XDG icon spec
also doesn't support this.
Currently, in case someone would attempt to add a localized icon, the
implementations would just read yet another icon and ignore any
localization hints.

> I'd say ignore this for now, localised screenshots are much more important IMHO and very few applications are doing that right now.

We support localized screenshots? If so, this is an extension of the
spec I have never heard of. Or do you mean the localized <caption>
tag, describing a screenshot? In that case, yes, would be cool if that
was used more.

Regarding splitting locales: This is something we are investigating at
Debian, since people there are much more sensitive about download
sizes. Also, the AppStream data is used for a lot more than just
desktop-applications there, so even people without any SC installed
might want it.
I don't plan to go for split locales in the near future (there are
bigger issues to handle), but it is definitely a possibility later.
Users don't change their locale often, it is usually configured once,
so I see the additional download as a minor, low priority issue.

>> What do we do about appinfo id conflicts? For instance, a single
>> repository can have two branches of org.gnome.Gimp, say "master"
>> (tracking 2.10.*) and "2.8" (tracking 2.8.*). Both of these would have
>> an id of "org.gimp.Gimp.desktop". In this setup, how can we tell the
>> difference between the app ids? Also, if they have the same icon name,
>> but different icon files, which one will be stored in the icon cache?
>
> At the moment, the last added "wins". I'm not terribly sure it's a huge problem, but you certainly could put the commit id in the <id> rather than the application "name" if we needed to support this. As long as we had some way of getting the xdg-app app "name" from the AppStream file I don't think it matters. I think renaming the file like we do the .desktop file would also work.

(Ab)using the <id> is pretty ugly though...

>> The way xdg-app handles conflics on the client is that you have to
>> specify which one you want when you pull, and you can have multiple
>> installed locally, but only one of the is "current". Only the current
>> one gets its files (e.g. desktop file) exported to the system, and the
>> other ones need to be started manually. Should we do something like
>> that on the repo too? i.e. mark one current and ignore the others in
>> the UI? Or should we extend the ids and icon names with the branch
>> name?
>
> I think we have to do the current thing; we don't want to return ~15 different "GIMP" applications when searching.

Jup, I fully agree - one point of AppStream is have one default choice
to install, so you don't need to browse through lots of different
versions of the same app. If users want GIMP, give them the latest
release. Users wanting a specific release of GIMP is something which
IMHO will happen only in rare cases, and those users should be
perfectly capable of using different tools than software centers to
achieve what they want.

>> The conflicts can also happen between different remotes. I.e. multiple
>> remotes can contain the same app. gnome-software has to handle that
>> somehow by showing a list of possible sources when installing the app.
>
> This sounds more like a #gnome-design discusssion, but I'm pretty sure Allans response would be "JDI without asking questions" -- i.e. we need to 'prefer' one remote, or have some kind of prioritisation even if it's as simple as remote-added-first-wins or remote-updated-last-wins. People who want more control than that can use the command line.

Yes :-) I currently consider multiple software components having the
same <id> a bug (results in a warning message) - if components with
the same <id> and the same priority are found, the component which was
processed first wins.
I'd be happy to change this to any kind of priorization, as long as
the end result is that only one component with the same <id> is
present at a time.

Cheers,
    Matthias