numixproject
Small monochrome icons in Gnome shell
Original brought to my attention in this issue in the Moka icon theme.
Starting with Gnome 3.16, Gnome shell shows small monochrome icons in the top panel. These Icons are available with the default applications of Gnome but other apps are missing these icons. Would you please consider adding these monochrome icons to your icons.
One that uses it:
One that doesn't:
If you provide
*-symbolic.svgicons inscalable/apps/folder, Gnome shell will use those icons.
We should probably talk about what we want to do about this. Some points to discuss:
- Requires designing and adding ~1500 new icons
- Debatable whether they should be added here or in the app theme repos (i.e. Circle)
- Means having to test conflicts with the current
scalable/appssymlinks which caters to HDPI screens - Possible naming conflicts with some status icons
I think it's a bad design decision by the GNOME devs. Not only it leads to symbolic icon/app icon inconcistencies but also it complicates the distinction between similar apps and I think in that place symbolic icons look dated or as if using the HighContrast theme.
I ended up disabling the Top Bar app icons altogether and possibly there will be an extension restoring the pre 3.16 behaviour.
It's a fairly limited case and I'd certainly prioritise other missing base theme icons but if someone feels like making the icons please go ahead :)
Thinking about a way to work around the symbolic icon display am I right in assuming that adding symlinks *-symbolic.svg for each and every file in scalable/apps would do the trick?
Yup :/ we're basically given the choice now of either ditching GNOME from our inherits list or adding all the icons. The work around you suggest would work, but it isn't ideal.
To me, this is a very questionable move of the GNOME devs as well.
Before further getting into this, one question: is this here to stay? I mean, why bother about it at all if this changes again with GNOME 3.18?
A couple of preliminary thoughts (I intend to do some testing, and I expect some "devils in the details"):
-
"Requires designing and adding ~ 1500 icons" Not necessarily. This might be an opportunity to bring in the Numix "Technic" icon theme from the Numix labs (?). iirc that one is monochrome and quite complete, so e.g. taking a white-ish/grey-ish colour variant of all those app icons and renaming them into *-symbolic.svg might be worth considering?
-
"base or Circle" I would say base, as these are icons for the panel, and as they do not have to be circle/square icons, also related to 1). At the same time, also relating to "adding symlinks
*-symbolic.svgfor each and every file inscalable/apps", if these new symlinks were to be placed in base, this would mean cross-repo symlinks (symlinks in Numix base with targets in Numix-Circle), which might be problematic. -
"symlinks in
scalable/apps" This would apply if these icons are added to Circle (?). In base, they could be added toscalable/apps, no symlinks needed there. -
"possible naming conflicts with status icons" Might not be too bad. "symbolic"-named status icons are only placed in
scalable(except of course for the battery status icons), so any upcoming conflicts should be manageable. -
"ditching GNOME from our inheritance list" I have been wondering before if indeed GNOME by now is even needed anymore, as Numix base has been growing and is covering a lot of ground by now. Not sure if all is covered, though.
If GNOME is ditched from the inheritance line, would that mean that the inheritance line could be removed completely, because iirc hicolor as fallback icon theme is inherited anyways, no matter if explicitly mentioned in the inheritance line or not?
Another thought: GNOME icon theme has been succeeded by Adwaita icon theme, and e.g. Ubuntu 15.04 does not inherit from GNOME anymore, but from Adwaita. Still, I assume that e.g. Ubuntu 14.04 LTS is still inheriting from GNOME, so Adwaita probably cannot replace GNOME for the Numix inheritances. But the inheritance line could be updated to include Adwaita,gnome,hicolor (?).
Technic couldn't be properly used because its symbols were designed on a 48px template where as these are for 16/22/24px.
I only say GNOME becauss that's what Numix references, it could be that these new icons are in Adwaita too.
Ah, too bad about Technic.
These icons should be in Adwaita and in GNOME, so yeah, I guess it would either be inheriting GNOME/ Adwaita + GNOME (would probably not matter for this issue), or not inheriting GNOME at all.
Well, I for one would prefer not to inherit those at all, i.e having only proper app icons displayed.
Agreed that not inheriting from GNOME is appealing, the question is whether Numix base is up to that.
And it would still have to be tested whether not inheriting from GNOME actually solves this issue. In theory it should, but to me on first sight this looks like a somewhat complex issue, so testing is needed.
The check as to whether base is up to the task is quite simple: other than the scalable/apps/*-symbolic.svg icons in questions does GNOME/Adwaita have any icons that Numix does not? If it does they those icons needed to be added to Numix.
I believe the user who originally reported this to Moka did that testing and found that because it's just a standard icon lookup removing GNOME/Adwaita from inherits is sufficient to solve the problem.
Well, I am not quite sure what is going on here, and probably someone who is actually running Gnome Shell should have a look at this: in a first test I did, removing GNOME from the inherits line in Numix base or removing the inherits line completely had no effect e.g. on the symbolic icon being displayed for file manager. If this is reproduced, then that would mean that some other mechanism is at work here.
Unfortunately, so far I have not come across a proper implementation guideline for these icons. This should be documented, should it not?, because it must have been clear from the outset that if only the GNOME default applications are covered by this, there will be many many many apps that are not.
Looking at this latest pull request from @wa4557, Numix base now seems to cover Ubuntu completely :)
https://github.com/numixproject/numix-icon-theme/pull/486
It does. However there are a lot of icons in the gnome icon theme that are not present in Numix. I made a small check and there are roughly 200 icons solely in the gnome icon theme. I could provide a list if you wish
It's even more screwy. Deleting gnome from the inherits didn't change anything for me too.
After I had effectively deleted gnome/scalable/apps (renamed the directory) the place of the symbolic icons just remained empty, no Numix Circle app icon was shown.
After the creation of a Numix Circle icon with one of the above names I couldn't get to a proper Numix Circle icon either but instead just a monochrome white circle (the baseplate).
So yeah, it looks like without further ado only monochrome icons will work there. The behaviour is hardcoded in the Shell theme.
I might be missing s.th. here, but why are only the "symbolic"-named icons in GNOME of relevance when determining whether Numix base is up to the task of not inheriting GNOME anymore? I would think this applies to all icons in GNOME icon theme, not only "symbolic"-named ones. E.g. the icons that Ubuntu used for the network icons were from GNOME icon theme, and they were not "symbolic"-named. Of course, these icons might also be present in hicolor and would still also be picked up without GNOME.
According to the Moka issue discussion (and the linked post) the appMenu icon behaviour is determined (so effectively "hardcoded") by the Gnome Shell theme.
Ah, I see now, completely misunderstood the list above. Those are the icons displayed for the active application :)
I do not understand the linked post https://plus.google.com/+WorldofGnomeOrg/posts/ZEbfygDA4sk.
"symbolic: Try to draw a symbolic icon. If no symbolic icon can be found looking at all possible icon names, fall back to the requested name."
That is nowhere near clear to me, unfortunately.
Where does this even come from? Official documentation? Well what I take away is that regular is probably the value I'd prefer for -st-icon-style
Err no. Editing the vanilla shell theme stylesheet /usr/share/gnome-shell/theme/gnome-classic.css accordingly was of no avail.
Btw, the underscores are hyphens actually.
Well, from what I can tell, the "symbolic"-named icons can be colour-themed by the GTK theme. So no matter which colour such an icon might have, apparently it is then "colour-themed" monochrome.
Still, even the symbolic value from above mentions "fall back to the requested name". That sounds like in absence of a symbolic-named icon, a regular icon should be picked up (?). What a mess.
Btw, such monochrome "colour-themeing" of "symbolic"-named icons probably also means that adding "symbolic"-named symlinks pointing to the regular-named app icons as targets would not work: these symlinks, because they are "symbolic"-named, would not be displayed as coloured icons, but "monochrome", which depending on the method used for colour-themeing, might mean "just the baseplate", as described above.
I could now go on speculating why removing the GNOME inheritance does not seem to change anything for the default symbolic GNOME app icons in the top bar. But there is no point in speculating, and we might come across some actual evidence at some point.
Anyways, so far it seems that removing the GNOME inheritance does not address this issue, so that inheritance might as well stay.
As to designing +1500 symbolic icons: I am not sure if it would be even possible to make these distinct enough individually. Arguably it makes more sense anyways to tolerate a couple of GNOME monochrome symbolic icons and have all the other app icons displayed in colour. As it currently seems, this is an inconsistency by design from the GNOME side that cannot be addressed from Numix's side.
The most elegant way to go about this would probably be to disable the active app icon in the top bar altogether, as @palob has already done.
@dirtydancing the disabling of the app icon in the top bar requires GS theme modification which is not within the scope of the Numix icon themes. I'd not realised that as part of the process in picking up the *-symbolic.svg app icons it converted them into monochrome icons of the themes choosing (I knew it did it in other places, just not here).
@palob you might have to completely remove the icons (rather than just renaming them) to get the effect you want, icon themes are weird like that sometimes.traces
As for removing GNOME from the inherits, it's not just a case of it seeming okay in testing we would have to actually make sure we had all the icons in GNOME in Numix too because they'll always be that one outlier user who's using that weird application and suddenly ends up with a broken experience. However, I do think that Numix is close to completion enough that removing GNOME from the inherits list while still maintaining a consistent interface is an achieveable goal.
TL;DR: looking this over, I'm thinking that adding all missing icons to Numix and then removing GNOME is the way we should solve this issue.
Agreed that disabling the top bar active app icon requires individual manual intervention from the user and cannot be done via Numix icon theme. The same goes for setting the value for the already infamous -st-icon-style, cf. above. And the same goes for choosing a GTK/GS theme and a possible GNOME Shell extension in general. All not a matter of Numix icon theme.
Users would have to get active themselves beyond merely selecting an icon theme in order to achieve consistency between the top bar active app icons, an inconvenience which is prompted by a design decision of GNOME.
While I agree that adding all missing icons to Numix and then removing the GNOME inheritance is a good move, this might not solve this present issue with small monochrome icons in GNOME Shell, but rather the (separate and more general) issue of not "falling back" on GNOME icon theme anymore.
The evidence so far suggests that removing GNOME from the inheritance line in Numix base does not solve the present problem. Of course this is not set in stone and might change with new evidence.
And btw, as this issue came up for Moka icon theme, cf. above: on my Ubuntu machine (versions via PPA), Moka icon theme inherits from Faba icon theme, and Faba icon theme does not have an inheritance line at all. This means that GNOME icon theme is not inherited over there, and apparently the monochrome symbolic icons are also displayed with Moka? This would be even more evidence that it is irrelevant to the present problem whether there is a GNOME icon theme inheritance or not.
Ah, that piece of evidence is not conclusive, as e.g. Faba-Mono inherits from Moka,Faba,gnome so GNOME is listed there. But then again, as I understand it, Faba-Mono is specifically for monochrome panels such as e.g. in Ubuntu and should not be needed in GNOME Shell (?). But of course I do not know the exact icon theme constellation of the user who originally reported the issue over at Moka.
Some more evidence that the inheritance line does not solve this issue: I checked with the current GitHub versions of Moka/Faba (not Faba-Mono) in Arch-based Antergos with GNOME Shell 3.16 (VM), and e.g. for Files the GNOME symbolic monochrome icon showed as active app icon in the top bar, although neither Moka nor Faba inherits from GNOME/Adwaita. Not sure why this is happening, but it is.
Also checked with EvoPop icon theme, which actually contains its own system-file-manager-symbolic.svg in symbolic/apps: The EvoPop symbolic icon was displayed in the top bar. After having removed/renamed that icon, not the regular EvoPop icon was displayed, but rather again the GNOME symbolic icon. EvoPop inherits from gnome,hicolor, but the GNOME symbolic icon was also displayed after I commented out the inheritance line. Might not be as conclusive as Moka/Faba, but here it is.
After the latest update in Antergos GNOME, the icon displayed for Gnome Tweak Tool looked different, and indeed: now this is a "symbolic"-named icon located in hicolor. And with this icon in hicolor, the fallback icon theme, it probably would not matter if all inheritances are removed in Numix, because this icon would always be picked up when a "symbolic"-named icon is looked for.
This seems to be an exception, though, as usually these icons seem to be located in GNOME icon theme or Adwaita icon theme:
With the evidence piling up (still would be good if someone could reproduce this), the way to go for Numix (base) seems to be to provide Numix icons for those "symbolic"-named icons that GNOME uses, so as to at least override the GNOME icons. For file manager, this probably would include six different versions for the six different folder styles, which would then be included in the folder style switcher.
To differentiate, these "special" icons could be placed in a new folder symbolic/apps (otherwise in scalable/apps).
Overall, that icon list should not be too long, and at least that would be Numix-style monochrome "symbolic"-named icons for more consistency. This is still in need of more evidence and consideration.