AppStream: dealing with icons

[David Kalnischkies]

On Thu, Jan 27, 2011 at 13:57, Richard Hughes <hughsient at gmail.com> wrote:
> 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.


It's up to the distribution how it wants to ship the icons.

Shipping all icons in one big batch introduces problems for some
for others this is the perfectly fine solution. As the app-data.xml is
created by the distribution it can say:
<icon type="stock">game</icon> to display whatever is the default icon
do indicate that the application is a game (or in the default search path
for icons)
<icon type="url">http://example.org/game.png</icon>to point to a specific
location to get the icon from, e.g. for closed source stuff with messy
licenses even on their icons.
<icon type="local">/usr/share/foo/icons/bar.png</icon> you have a
package shipping all the icons (in not default places).
And all the other types you might come up with…

The thing is, you could even mix that: Maybe the "local" file is not
available and you are currently offline, then you can at least display the
"stock" icon…

Also, we had quiet a few voices saying that maintaining a bundle
is/could be a pain as soon as applications update their icons or
new applications are added to the database…


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

One size fits it all doesn't even work for a single distribution:
I run debian on my laptop as well as on my phone -- the screen size
differs largely as you might imagine. Also some users might prefer
smaller/bigger icons than the "normal" user…


Best regards

David Kalnischkies