Only inherit themes which are really needed

[alexxcons]

Hi flat-remix team,

now that the related xdg merge request got merged and v0.18 of the spec got released, I am starting my mission to get the "Inherits" attribute right for popular icon-themes to prevent potentially missing icons 🙂

Currently flat-remix-blue-dark has (probably same for all the other colors):

Inherits=breeze-dark,elementary,gnome,hicolor

I wonder why breeze-dark, elementary and gnome are listed here ... is flat-remix lacking fd.org icons which need to be provided by these?

If there is no strong reason to keep them in the Inherits list, I would suggest dropping them.

If one/some of the other themes need to stay on the list for some reason, it makes sense to have a section in the README.md to explain packagers that the flat-remix-icon-theme package should have a hard dependency on the other listed themes.

[daniruiz]

Hello!
Well this was a common practice, we are unable to create 100% of the icons for all the desktops, so with inherit we could set which icon themes we want to use as fallback. Otherwise the desktop choose whatever it likes, and ends up looking bad. They aren't hard dependencies, but as far as I know there is no other way to set fallback icon themes and their order of priority

[alexxcons]

Well this was a common practice, we are unable to create 100% of the icons for all the desktops, so with inherit we could set which icon themes we want to use as fallback.

Yea, you should not need to create icons for all kind of desktops. (Otherwise, you will end up having 10+ other themes in the Inherit section one day)

If an App requires additional icons which are not part of the standard, according to the spec,that App should install these additional icons itself into the "hicolor" folder. It might make sense for an app to install a bright and a dark version to match the currently used theme.

If an App misses installing these additional icons and relies on having other themes in the Inherit tree, you should report that to the app developers. If these icons are used by multiple applications, it might make sense to request a new icon-name for them on freedesktop.org, so that all themes can ship that icon.

In case you want to make sure that even such Apps which don't follow the standards are serviced with foreign icons when using flat-remix, it is fine to still keep breeze-dark, elementary and gnome in the Inherits section. Though than you should make sure, that whenever flat-remix is installed, as well breeze-dark, elementary and gnome are installed (hard dependencies). Since otherwise, users of the mentioned Apps still won't have icons when installing only flat-remix ... and they won't know why icons are missing/looking bad and which theme to install to get them right.

The best place to define hard dependencies to other themes probably would be, to write that into the README.md, so that packagers do know ... it might be required to open issues against distros as well, in order to inform them on the dependency.

(Though keeping gnome as a fallback theme .... an ancient theme which not even gnome itself uses anymore? I really don't think you need that one)

[daniruiz]

Well, the inherit trick is usually used for symbolic icons, not app icons. I don't mean to have full support for all app icons, that would be crazy, but the symbolic icons is another thing. It's hard to support all symbolic icons for all desktops, thus having a way to set the fallback theme is great, as you can choose the usually more similar icon theme. Otherwise you might have flat-remix with a flat looking symbolic icon and then the missing one being full color, which looks terrible.

I understand what you say, but that only works in a perfect world where all desktops follows the standard.
It would be great that instead of using inherit the wrong way there was an option to set a fallback theme, something like a soft dependency that lets the designer choose the order of preference of icon themes in case an icon is missing.

[alexxcons]

having a way to set the fallback theme is great, as you can choose the usually more similar icon theme. Otherwise you might have flat-remix with a flat looking symbolic icon and then the missing one being full color, which looks terrible.

Well, the point is that it does not work. Currently, if you install flat-remix via package manager, none of the other themes will automatically be available. So it pretty much can and will happen that (symbolic) icons are missing / wrong icons will be used. How is the user supposed to know that it is required to install some additional theme manually to get things right?

If it is sufficient to have one of the listed Inherit themes as fallback, how about a conditional package dependency. So that, at minimum one of them will be installed together with flat-remix ?

It would be great that instead of using inherit the wrong way there was an option to set a fallback theme, something like a soft dependency that lets the designer choose the order of preference of icon themes in case an icon is missing.

Even that would not help much for the described use-case ... the question which remains is: How is the user supposed to know that some other theme needs to be installed together with flat-remix ?

[daniruiz]

They don't need to be automatically installed, they are already installed if you use elementary, plasma, or any other desktop that already includes those icon themes. Is in these cases where the Inherit trick is meant to work, not everywhere.
The user isn't supposed to know anything, they just install it and it will work whatever they use, that's the idea.

It is sufficient to have only flat-remix installed, but if any icon is missing in KDE for example I want to have an option to fallback to breeze theme, which I prefer, not whatever the system thinks, or just hicolor.

You are taking the Inherit trick as a hard dependency, but we don't use it that way. It's just a hack we use to choose which icon theme use as a fallback, no need to have all of them installed. Maybe as you say this is no longer going to work, I don't know, but that's the only way we had until now to do it

For example I just tested removing some icons in my theme and removing the Inherit value and the missing icons now look terrible. On the other side if I set it to Adwaita it now uses the icons from that theme which isn't perfect but way better than the icon that it used before

[alexxcons]

They don't need to be automatically installed, they are already installed if you use elementary, plasma, or any other desktop that already includes those icon themes.

That is a very big "if". As a result, you discriminate all users which only do install a single application from said DE's, and as such will possibly have broken icons.

You are taking the Inherit trick as a hard dependency, but we don't use it that way.

Nothing about a "trick" or a "hack" here. If you rely on icons from a foreign theme, then that theme should be available. Why you think it would be a problem to specify breeze-dark | elementary | gnome as conditional hard dependency ?

For example I just tested removing some icons in my theme and removing the Inherit value and the missing icons now look terrible. On the other side if I set it to Adwaita it now uses the icons from that theme which isn't perfect but way better than the icon that it used before

That example once more demonstrates that for themes which do not ship all icons, it would be nice to have a hard dependency, to have a guaranteed fallback. Otherwise, only DE's which have the said themes preinstalled will profit.

[daniruiz]

That is a very big "if". As a result, you discriminate all users which only do install a single application from said DE's, and as such will possibly have broken icons.

What? why? who said that?
I repeat, you don't need any of them to make flat-remix work. But in case there is a missing icon for whatever reason, I want to be able to tell the theme which icon I prefer, and not an ugly 'missing-icon' icon or hicolor. That's all
It's not a dependency, you don't need the themes from Inherits, it's just something nice to have.

Look, there is no such thing as a theme that ships ALL icons. There are million of icons and it's not humanly possible to fill them all. Flat-Remix supports all (as far as I know) icons from fd.org, but that are not ALL icons that could be available for any desktop, there are lots of variants and additions outside of the standard

That example once more demonstrates that for themes which do not ship all icons, it would be nice to have a hard dependency, to have a guaranteed fallback. Otherwise, only DE's which have the said themes preinstalled will profit.

That was just an example... what do you mean with ' themes which do not ship all icons', that doesn't exist. It's not humanly possible. Check just one of the Flat-Remix variants, how many icons it has. With 19247 svg icons and that's not even near to being 100% complete for all DEs
In addition from time to time DEs change the name of some of their icons and introduce new ones, which until we support them they would look ugly, and gives bad impression of the theme

[alexxcons]

Look, there is no such thing as a theme that ships ALL icons. There are million of icons and it's not humanly possible to fill them all. Flat-Remix supports all (as far as I know) icons from fd.org, but that are not ALL icons that could be available for any desktop, there are lots of variants and additions outside of the standard

As I said before, if an application of some DE uses some icon which is not part of the fd.org spec, that application should provide that icon on it's own by installing in into "hicolor". There is no need for a theme to provide millions of icons neither directly, nor by listing various other themes in the "Inherit" section because they might ship DE-specific extra icons.

what do you mean with ' themes which do not ship all icons',

Themes which do not ship all fd.org compliant icons, sorry for being imprecise.

being 100% complete for all DEs

IMO it makes sense to rather consider "applications", not "DEs", since in the end applications do use icons, not DEs. You always can install an application without installing the whole DE, and there are applications which do not belong to a DE at all.

In addition from time to time DEs change the name of some of their icons and introduce new ones, which until we support them they would look ugly, and gives bad impression of the theme

Which application of the DE concretely did so? Did you report that issue to the developer of the application? It is indeed bad that app developers are ignorant regarding the fd.org spec and like this shed a bad light on your theme (and other 3rd party themes). Though IMO in such a case theme authors should point to these applications to fix the problem on their side, instead of adding more and more foreign themes in the Inherits list. Because in the end, that will make the fd.org specification worthless.

[alexxcons]

Related: The spec as well allows the possibility for the icon loader of an application to define an implementation-fallback theme which should be used:

The lookup is done first in the current theme, and then recursively in each of the current theme's parents, and finally in the default theme called "hicolor" (implementations may add more default themes before "hicolor", but "hicolor" must be last)

KDE so far did not implement an implementation fallback, though they are currently on it: https://invent.kde.org/frameworks/kiconthemes/-/issues/3