Web lists-archives.com

Re: How to properly install app icons?






2016-03-14 13:12 GMT+01:00 Matthias Klumpp <matthias@xxxxxxxxxxxx>:
2016-03-14 12:21 GMT+01:00 Elvis Angelaccio <elvis.angelaccio@xxxxxxxxxxx>:
> [...]

Hi!
Thanks for raising this issue!
/me puts his AppStream / Freedesktop hat on

> 1. Should KDE apps install their app icon even if it's already in breeze?
> From what I understand, icons installed by the apps are used as fallback if
> breeze is not installed, so that would answer this first question.

Correct

> But then why some apps don't install any fallback?

That is a bug - at time distributors mitigate that by having those
apps depend on the respective KDE icon theme so the applications have
an icon on non-KDE desktop environments too.
There is one exception though: If the app uses a default icon name,
like "system-file-manager", the icon doesn't need to be shipped at all
(more precise: it *must not* be shipped) and the app references the
system default icon.

See [1] for a list of default icon names which should be present in a theme.

This exception is a problem for AppStream, since it means KDE apps
will have a GNOME icon in software stores if they are generic
applications, or vice versa. I am looking for solutions to this
problem, but that's a fringe issue at time.

[1]: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

> 2. Is enough to install the app icon in .svg (or svgz) format? Why do some
> app install also 16x16 or 48x48 .png icons?

16x16 is likely too small for our modern desktops, for an app icon, so
having it as 48x48 or - as I would recommend - at least 64x64 is the
way to go. Having a 64x64px icon or any bigger size in hicolor ensures
that the app will show up in software stores which are based on
AppStream.
The Freedesktop spec allows any icon size but suggests 48x48px. As
said, I think 64x64 is better at time ^^

Installing icons in different sizes decreases the resize overhead
desktop environments have to do, and of course having a bigger icon
prevents DEs from upscaling icons, leading to pixelated icons.

Toolbar icons should ideally be available in smaller sizes.

The SVGZ icon format is not allowed by the official specification for
icon formats at all (see [2]), but it seems to be supported by most
DEs now, and maybe we should add it to the specification to formally
allow it (I'll talk to some people).

Shipping only vector graphics (.svg or .svgz) is something I would
strongly advise against, it's also not really something the icon spec
wants people to do. The main point is that rescaling a bitmap is a
relatively cheap computation, while rendering an SVG image is
expensive.
The rendering result also needs to be cached somewhere and the DE has
to keep a rendering cache for every user, duplicating rendered bitmaps
in the user's home directory and constantly needing to keep the cache
up-to-date. Especially when lots of icons need to be rendered, this
results in a slowdown or icons being available much later when the
desktop environment is started for the first time.
Having low-end hardware (think of mobile phones) render lots of SVG
images by default is also not a great idea.
So, ideally the rendering should happen once to appropriate sizes,
e.g. as part of the applications build process. The additional storage
space needed IMHO outweights the problem of re-rendering SVGs at the
user's side again and again.

[2]: https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

> 3. Should we update these app icons from Oxygen to Breeze?

Most likely the answer to that question is yes.

Hi Matthias,
thanks for this very detailed answer.

I have one more question though: according to the documentation in [1],
the CMake macro ecm_install_icons (which most apps use) does not accept .svg extensions, but only .svgz

Shouldn't we edit this macro to also accept .svg icons?

[1]: http://api.kde.org/ecm/module/ECMInstallIcons.html


Cheers,
    Matthias


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