Web lists-archives.com

Re: appstream icons and the hicolor madness we have in KDE software

To explain how we currently find icons (from an appstream-generator
perspective, but appstream-builder works similarly):

We encounter an application which has an "Icon=" field in its .desktop
file. If it is an absolute path, we load that icon directly and
complain about it, since an absolute path does not allow selection the
appropriate size and scaling level.
In the other case, we look into /usr/share/hicolor/ for the right
icon, first in the apps/ path, then in others. We select the right
icon based on the size we want (at least 64x64px), and prefer bitmaps
over vectorgraphics (.png >> .svgz >> .svg) for performance reasons.
If we found nothing, we turn on the global icon theme search, and may
or may not use heurisitics to determine which icon theme to select.
This becomes especially difficult if people want their own icon theme
to override default icons, e.g. Ubuntu wants to use the Humanity
theme, Elementary wants its own theme etc.
So, in case heuristics fail, we just search in for the right icon name
in all themes, starting with the one seeded by the generator user
(Humanity in case of Ubuntu), and then continueing alphabetically
(Adwaita >> Breeze).
In the end, we add the found and properly resized icon to the pool and
set an AppStream icon type for "cached" icons and one for "stock"
icons, containing the stock icon string found in the .desktop file, so
software centers can theme the icon to what they want, if they want to
do that.

GNOME ships icons for all its apps in hicolor/, that's why they don't
have this problem. This also means that if you install a GNOME app on
$OTHER_DESKTOP, it will have its icon present there and not show up
without one, while for KDE apps with the current model, distributors
need to ensure the app depends on the Breeze icon theme.

So, to make a comment on the issue, I would like to ask you to think
about good ways to have apps ship their own, and the right, icon on
their own, because IMHO this brings some quite big advantages.
This won't solve the issue for generic icon names, as used by Dolphin
and Nautilus though, for that I am thinking about introducing a new
.desktop file key ("X-VendorIcon") to set the vendor icon name for
that app. The generic alias can then be set by the theme by symlinking
the icon.