numixproject / numix-icon-theme

Official base icon theme from the Numix project.
http://numixproject.github.io
GNU General Public License v3.0
778 stars 87 forks source link

Small monochrome icons in Gnome shell #485

Closed Foggalong closed 1 year ago

Foggalong commented 9 years ago

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: 51d89ede-f74d-11e4-8eae-c150a1d06162

One that doesn't: 69054ae4-f74d-11e4-85ac-d3e1c5b99d18

If you provide *-symbolic.svg icons in scalable/apps/ folder, Gnome shell will use those icons.

We should probably talk about what we want to do about this. Some points to discuss:

palob commented 9 years ago

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?

Foggalong commented 9 years ago

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.

dirtydancing commented 9 years ago

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?

dirtydancing commented 9 years ago

A couple of preliminary thoughts (I intend to do some testing, and I expect some "devils in the details"):

1) "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?

2) "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.svg for each and every file in scalable/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.

3) "symlinks in scalable/apps" This would apply if these icons are added to Circle (?). In base, they could be added to scalable/apps, no symlinks needed there.

4) "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.

5) "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 (?).

Foggalong commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

palob commented 9 years ago

Well, I for one would prefer not to inherit those at all, i.e having only proper app icons displayed.

dirtydancing commented 9 years ago

Agreed that not inheriting from GNOME is appealing, the question is whether Numix base is up to that.

dirtydancing commented 9 years ago

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.

Foggalong commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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

andia89 commented 9 years ago

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

palob commented 9 years ago

The icons to work against:

symbolic

palob commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

palob commented 9 years ago

According to the Moka issue discussion (and the linked post) the appMenu icon behaviour is determined (so effectively "hardcoded") by the Gnome Shell theme.

dirtydancing commented 9 years ago

Ah, I see now, completely misunderstood the list above. Those are the icons displayed for the active application :)

dirtydancing commented 9 years ago

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.

palob commented 9 years ago

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

palob commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

Foggalong commented 9 years ago

@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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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.

dirtydancing commented 9 years ago

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:

gnome-tweak-tool-symbolic

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.

andia89 commented 9 years ago

Hmm why not use the Technic theme for these scalable icons? I mean currently also 48x48 icons are scaled down and the Technic icons are also in a scalable directory. At least for me they seem to be the icons that would fit exactly

dirtydancing commented 9 years ago

The Technic icons have not been designed as symbolic icons in size 16x16. They will scale too small.

Comparative screenshots of Adwaita, EvoPop and Numix with Technic icon renamed as "symbolic":

adwaita evopop numix

dirtydancing commented 9 years ago

Here is an overview with possible "symbolic" icons based on the present size 16x16 folder icons. Apparently these icons are scaled somewhat in GNOME Shell, as they look a bit bigger than 16x16.

Starting with default Adwaita, then continuing with Numix folder styles 1 to 6 (this is just a draft overview to get a visual impression, e.g. the "symbolic" Numix default style 6 probably could still be refined):

adwaita style1 style2 style3 style4 style5 style6

The "symbolic" icons for file manager and also for terminal are two of the most prominent ones. Arguably it would make sense for Numix base (for file manager via Numix-Folders) to include at least the most important icons as "symbolic" icons, to enable a consistent Numix icon experience. This would cover the current GNOME Shell 3.16 default, and it would also cover cases when users opt for "symbolic" icons.

On the other hand, there would be no need for these additional "symbolic" icons if it were possible to disable the GNOME icons from showing (which still would not account e.g. for gnome-tweak-tool-symbolic.svg in hicolor). So far, there seems to be no way to do that, but is this really so?

dirtydancing commented 9 years ago

One more thought: it might arguably be the most "consistent" approach to not add any Numix symbolic app icons for this present purpose at all.

E.g., gnome-tweak-tool-symbolic.svg in hicolor/scalable/apps arrived with current Gnome Tweak Tool 3.16.2 a couple of days ago. This means that whenever an app adds a symbolic icon, in order to keep up, Numix would have to create a Numix one.

On the other hand, if there are no Numix symbolic app icons at all, the monochrome symbolic active app icons in the GNOME Shell top bar will consistently be non-Numix icons, whereas the regular non-symbolic icons will consistently be Numix icons.

Of course, this is only viewed from the Numix icon theme perspective; further individual non-default GTK theme/GS theme/extension interventions are up to the users.

E.g., I checked in Antergos with the shipped default Gnome Shell theme Numix-Frost: adding .app-menu-icon {-st-icon-style: regular} in gnome-shell.css worked and resulted in all active app icons in the top bar showing as regular icons.

183amir commented 9 years ago

Hey guys, I just wanted to add some more informations here. I noticed that in Nautilus the app actually requests a symbolic icon in the code. ( This is just a fact that I am stating; I am not concluding anything) There is also this extension that hides the app icons all together.

palob commented 9 years ago

Isn't this the icon to be shown with file operations progress widgets?

The extension is the one I'm using. Thanks for posting the link.

dirtydancing commented 9 years ago

Notice: another icon in hicolor: gnome-pie-symbolic.svg, cf. https://github.com/numixproject/numix-icon-theme/issues/498.

palob commented 9 years ago

With Fedora 22 there are more icons than the one posted above: All preinstalled apps including Libre Office save for Firefox have symbolic icons. The non-Adwaita ones can be found in .../icons/hicolor/symbolic.

dirtydancing commented 9 years ago

With Arch, the "symbolic" app icons outside of Adwaita are mostly located in hicolor/scalable/apps. In addition to those, currently in hicolor/symbolic/apps in my setup there are cheese-symbolic.svg and gnome-boxes-symbolic.svg.

@palob On another note: If you have the resources to have a look: What kind of "legacy" status icons are displayed in Fedora 22? Please cf. the current conversation over at https://github.com/numixproject/numix-icon-theme/issues/498.

palob commented 9 years ago

Do you think it is a Fedora-specific issue?

I probably haven't took note of the status icon issue as I find the new 3.16 legacy status icon drawer super-annoying and hence banned the icons back to the top bar using the TopIcons extension (which is a bit buggy itself unfortunately).

dirtydancing commented 9 years ago

I do not think this is a Fedora-specific issue.

The status icons are the same in Arch whether I stay with the default legacy status icon drawer or whether I use the TopIcons extension. For me, the original (status) icons are showing, not Numix icons. I was just wondering whether in Fedora, there are any Numix status icons showing "out of the box".

dirtydancing commented 9 years ago

Some more information relating to GNOME and Fedora 22. I came across this thread:

http://desktop.fedoraproject.narkive.com/rO5LaPgC/symbolic-icons-in-app-menu-not-ready-for-f22

Apparently, these icons are located here:

https://github.com/gnome-design-team/gnome-icons/tree/master/apps-symbolic/Adwaita/scalable/apps

This means that these "symbolic"-named icons are covering the Fedora default apps. So it is not only the GNOME apps that are covered so far.

Overview screenshot:

symbolic

dirtydancing commented 9 years ago

Another observation: so far, I have checked with a couple of apps if the *-symbolic.svg icon, when placed in scalable/apps, is displayed as active app icon in the top bar in GNOME Shell 3.16. With Arch/GNOME, this has worked e.g. also for VLC, and as VLC is a Qt app, this is not limited e.g. to GTK apps. So this seems to be toolkit-independent.

At the same time, I would doubt that VLC requests a "symbolic"-icon in the app code (did not check for that, though) (?).

As Numix is not limited to a specific distro, there seems to be no point to select the Fedora default apps for Numix "symbolic"-named app icons. So far, to me it still seems best and most "consistent" to not add "symbolic"-named app icons to Numix at all.

andia89 commented 9 years ago

Hmm, isn't vlc (and all the other apps) already placed in scalable/apps? After all there's a symlink from 48x48/apps to scalable/apps

dirtydancing commented 9 years ago

I am referring to vlc-symbolic.svg in scalable/apps in Numix base. I checked that with Numix base (not Numix-Circle) by copying and renaming an existing monochrome Numix VLC status icon.

dirtydancing commented 9 years ago

Just cross-checked with Numix-Circle: just as expected, when placing vlc-symbolic.svg in scalable/apps in Numix base, also with Numix-Circle selected this (monochrome) icon is displayed as active app icon in the top bar. When, as is currently the case, vlc-symbolic.svg is not present in scalable/apps in Numix base, the regular Numix-Circle VLC app icon is displayed in the top par.

andia89 commented 9 years ago

So this is the same bug as in #190 again? Would this problem be solved by our folder-symlink approach?

dirtydancing commented 9 years ago

No, this is a completely different matter, not related to https://github.com/numixproject/numix-icon-theme/issues/190 at all. Because all these somewhat odd and complex issues might be confusing, I repeat: this is not related to https://github.com/numixproject/numix-icon-theme/issues/190 at all :)

This issue is relating to an entirely new app icon category (not status icon) with *-symbolic.svg named icons, displayed as the active app in the GNOME Shell top bar starting with GNOME 3.16.

dirtydancing commented 9 years ago

Well, on further reflection, there might be a link from this issue to https://github.com/numixproject/numix-icon-theme/issues/190 (just speculating here because nothing of this seems to be documented): As we have seen over at https://github.com/numixproject/numix-icon-theme/issues/190, apparently something in the icon lookup has changed with GTK 3.16, at least for GNOME Shell: now the status/tray icons with distinct status icon names are displayed, whereas pre-GTK 3.16, somehow these status/tray icons are not found further down in the inheritance line (in Numix base), but rather are "blocked" by the (Numix-Circle) app icons.

Of course there are further details which complicate things: e.g. there seems to be a distinction between GTK-apps and non-GTK-apps over at https://github.com/numixproject/numix-icon-theme/issues/190, and so far in Arch/GNOME 3.16, in relation to https://github.com/numixproject/numix-icon-theme/issues/190 for me this has worked e.g. for Redshift only for a specific directory, and not e.g. for Shutter. But still, there might be a general connection here.

In this present issue, the *-symbolic.svg icons are found no matter where they are located in the icon theme inheritance line, be it Numix base, Adwaita, gnome or hicolor. This might indicate that there is a stricter lookup for a specific icon name in GNOME 3.16/GTK 3.16, and that this goes for the *-symbolic.svg icons in this issue as well as for the status/tray icons in https://github.com/numixproject/numix-icon-theme/issues/190. This might help with understanding what is actually going on over at https://github.com/numixproject/numix-icon-theme/issues/190.

dirtydancing commented 9 years ago

One more observation: Also other applications are including *-symbolic.svg icons.

E.g. Lollypop includes usr/share/icons/hicolor/scalable/apps/lollypop-symbolic.svg, cf. e.g. Package Contents https://www.archlinux.org/packages/community/any/lollypop/. lollypop-symbolic.svg is displayed ootb in the GNOME Shell 3.16 panel as active app icon (Arch/GNOME).