Expand Inheritance Lines?
Closed this issue · 15 comments
Now that Plasma 5 and KF5 applications trickle down to the last major distributions I think we should add breeze
to the inheritance line in order to avoid blank spots.
What was the reason again the line reads just Inherits=gnome,hicolor
and doesn't include, say elementary
or Adwaita
?
Ah, the inheritances. I am still not sure what exactly is going on in the background, but as I understand it, the intended way to go is to rather remove the inheritances than to add new ones.
Evidence (at least for GNOME) so far appears to suggest that there are "automatic" inheritances that work regardless of whether they are defined by a selected icon theme, cf. #485 (comment).
Furthermore, the more inheritances are added, the more problems could be caused once a distribution changes its default inheritances, e.g. Ubuntu from gnome
to Adwaita
, cf. #442 (comment).
Well, I'd consider blank spots instead of icons quite the issue. But I'll do some tests.
Yeah, I was under the impression that DEs with a "default" icon theme like elementary, gnome, breeze, automatically add it into the inheritance line? I might be wrong on that though. The reason gnome is in ours is that we still technically ship gnome with Numix so that it picks gnome to fill in the gaps before whatever the "default" theme was.
The reason for choosing gnome is a historical one based on the development of Numix, rather than one based upon the current state of gnome. The aim then now is to remove the inheritance completely rather than swap gnome for another one or add more.
For me breeze has a very different design than Numix (monochrome action icons etc...). Doesn't it look weird having breeze icons mixed with Numix ones?
Last time I tested it seemed that Oxygen (that plastic look theme which mixes much worse with Numix and which is a subset of Breeze) is the default fallback icon theme for KDE applications.
(Maybe this is subject to change to Breeze in the course of the ongoing KF5 transition)
@wa4557 As long as moving target #580 isn't entirely fixed we'll have that mix.
Same for elementary OS where as long as #437 isn't fixed users have to manually edit index.theme
in order not to encounter blank spots.
GNOME however seems to get things straight anyway. Briefly checking I couldn't find any glitches after editing the inheritance to hicolor
only.
@palob Regarding GNOME: removing hicolor
as well (or removing the entire inheritance line) should not make any difference either. Evidence suggests that hicolor
is always "automatically" inherited.
hicolor
anyway but GNOME seems to fetch Adwaita
/gnome
as fallback on its own.
Exactly, confirmed for GNOME, cf. also this older comment #485 (comment). iirc this is implemented via an "icon theme" named default
in /usr/share/icons
, which simply inherits Adwaita
.
Possibly there is a similar mechanism with KDE? E.g., with Arch/GNOME and some KDE applications, /usr/share/icons/
contains an "icon theme" with a folder named default.kde4
, and its index.theme
contains Name=Oxygen
. This seems to indicate that indeed currently Oxygen
is the default KDE fallback icon theme.
All of this is an argument for not including inheritances at all, as the desktop environments apparently include their own specific icon theme inheritance implementations, which are tailored to their specific needs. And as Numix caters to all DE/distributions, it would make sense to leave the inheritances up to those.
Maybe we should look into how for instance KDE apps behave in GNOME and vice versa.
Okular is one of those applications which still is not ported to KF5.
Have you got a KF5 app at hand?
So the good news is that the breeze
icons seem to be fetched without further ado.
(Just wondering what's up with "Zeitleiste" and "Umgebung")
However in the worst-case scenario all KDE apps come with that StartupWMClass
issue.
(KDE4 (like Krita 2.9.11) apps show up with their default icon in the Dash (to Dock)) here.
@palob in #1369: Revisiting Inherits: What is the reason we don't append themes like Adwaita, breeze, elementary (or respective -dark variants) to our inheritance line?
My understanding based on the above conversation is that these days most mainstream distros automatically include "must have" icon themes in the inheritance lines, so they no longer need adding as fallback options by specific themes. The only reason a theme might now want to add additional inheritances is if there's a particular theme which is close design wise and useful to have as a fallback for missing icons, which even though not perfect. would look closer than the default fallbacks.
Mind, I'm very open to being corrected if I've misunderstood that! inheritance has never been my area of expertise and even then it's a couple of years since I properly did any reading on this topic. Might be worth rolling up some VMs and doing some testing to see if the behaviour has changed at all.
Fixed.