AppStream: dealing with icons

Richard Hughes hughsient at gmail.com
Thu Jan 27 04:57:32 PST 2011


In appdata.xml we have:

    <icon type="stock">web-browser</icon>

Where the type can be stock, relative or absolute. We need to codify
this a lot tighter to actually create the icon data in the required
format.

I'm also not so sure about storing the icons on the mirrors as
./icons/24x24/foo.png as otherwise the application installer either
needs to go through PackageKit for each request, or online for each
one to be able to download these hundreds of tiny images as they are
displayed. In my opinion we want to recommend that distros tar these
up and the *package* manager (or PK) smatter them on the hard drive
whenever we add a repo or do a refresh of the repos so the client can
load results instantly. This means we get an application installer
that works offline too, without having to do a per-user cache and
messy stuff like that.

So, I propose:

* Stock can only refer to icons in the standard icon naming
specification. When I was developing app-install, I used this list
https://github.com/hughsie/app-install/raw/master/data/whitelist.dat
which may be somewhat useful as a reference. Stock icons are *not*
shipped in the appdata-icons.tar file.

* We store icons in appdata-icons.tar.gz, (or bz2, or whatever) with
the internal layout 22x22, 48x48, scalable etx

* We leave the recommended sizes to store in the appdata-icons.tar.gz
to the distros. On Meego it might make sense to ship 16x16 and 24x24,
and on Fedora 48x48 and svg might make sense.

* We explode the tarball of data at repo-add/repo-refresh to
/var/cache/appdata/icons/$repo_id/24x24 and use the convention <icon
type="relative">$repo_id/24x24/firefox.png</icon> where $repo_id might
be "fedora" or "main". We can provide "appstream-explode-icons
--repo=fedora /var/cache/fedora/appdata-icons.tar.bz2" if that makes
sense.

* For distros that want / need the icons on the server, we just add
<icon type="absolute">http://fedora.us/icons/24x24/firefox.png</icon>
to the spec and tell them to not ship an appdata-icons.tar file.

* We add a size attribute to <icon> e.g. <icon
size="24">$repo_id/24x24/firefox.png</icon> so the clients know what
sizes are available without stat'ing around in lots of directories.

* Anything in 24x24, 48x48 etc needs to be png, which we convert from
any random format (some desktop files reference .xcf files!) at
compose time. Only .svg files can be installed into scalable.

* We do not rename icons to match their desktop ID. If the same icon
exists for more than one package (e.g. convert-nosse and convert-sse2)
then the first encountered application wins and the second icon is
ignored. We store two entries in appdata.xml and one icon in
appdata-icons.tar

Comments please! Thanks.

Richard.


More information about the Distributions mailing list