selected desktop icons become black

[Fallen Dark]

Hello,

after I updated to Linux Mint 17.2 Cinnamon Edition, the following bug occured:

When I select one or more desktop icons, the icons become always totally black. I have attached a screenshot.

This happens when I use non-standard themes like Ambiance or Radiance or any other theme which isn't included by default. This doesn't happen when I use the standard Linux Mint theme.

This behavior didn't occur under Linux Mint 17.1.

So I think, it's a bug.

[Steve Morton (stevenmorton)]

I have this same issue 17.2 Cinnamon Edition, but it even happens when I'm using the stock themes. It doesn't happen in Nemo or file browsers dialogs (the normal alpha darkening happens), only on the Desktop itself.

[andrius (zymagoras)]

system settings -> theme -> change controls to "adwaita". that helped me.

[sedat1661 (sedat1661)]

Yes, we had same problem and i solve it by change control panel themes.

[Dirent (dirent)]

Unfortunately I removed the theme because of this issue.

[DelD. (deldadam)]

I've got the same problem: selected desktop icons are black.

I've spent a few days to investigate that issue (hundreds of 'googling'), and it seems to me in Linux Mint 17.2 and above:
- the shade color of selected desktop icon derived from the GTK3 background color of the selected theme always (that's wrong)
- the GTK 3 CSS rules, controlling the appearance of these icons are mostly ignored (except a few of them)
- some of these GTK 3 CSS rules are applyed wrongly

According to the docs, the active theme for control items should contain the CSS files for theming. If following CSS selectors exist in one of the appropriate CSS files in the "gtk-3.0" folder of your theme's for controls, then these ought to control/change the look&feel of desktop icons. These CSS selectors are:
.nautilus-desktop.nautilus-canvas-item (if Nautilus - Gnome - file manager used)
.nemo-desktop.nemo-canvas-item (if Nemo - Cinnamon - file manager used)

The appearance of selected state of desktop icons controlled by these selectors:
.nautilus-desktop.nautilus-canvas-item:selected
.nemo-desktop.nemo-canvas-item:selected

If I changed or added any CSS rules for the above selectors in the CSS file of any themes installed on my system: nothing happened.

To the addition of the above, I've found some interesting hints regarding the installed GTK libraries on Gentoo's web site involved in theming of Cinnamon. See here: https://wiki.gentoo.org/wiki/Cinnamon#Desktop_icons_text_color

The Gentoo site claims there is a known bug in GTK libraries versions earlier than 3.13. Linux Mint 17.2/17.3 are coming with GTK 3.10 by default. The site says, the desktop icons can be themed only 'system-wide', and adding the above listed CSS rules to Adwaita's CSS file (/usr/share/themes/Adwaita/gtk-3.0/gtk.css). I've tryed this w/o success. I'm not a dev. guy, but I think it would be worth to investigate this track too.

So my conclusion is: the appearance of desktop icon's selected state is NOT inluenced by these CSS selectors/rules at all, which is definitely a bug.

[Michael Webster (miketwebster)]

Most of this is intentional, actually. As of Nemo 2.6, the desktop icons are controlled here: https://github.com/linuxmint/nemo/blob/master/src/nemo-style-application.css

It was done with this commit: https://github.com/linuxmint/nemo/commit/e59cae7bd231bac01806458b377cd8c388503751

What theme is this occurring on?

We essentially hardcoded this because we wanted something on the desktop that would be readable regardless of background color/image, and because so many themes out there do not support Nemo. One particular one is Adwaita, which is used as the default on a few other distros that Cinnamon is maintained on. So the desktop would be nearly unreadable on these distros, depending on what type of background you were using. Some maintainers ("kit" OS's mostly) prefer to just supply meta-packages as-is, rather than doing some minimal configuration for the user (like selecting a supported theme).

Is it technically wrong? Yes - you're right, the theme should dictate this and generally anything like this.

On the other hand, duplicate bug reports have dropped nearly to nothing. Obviously there'd be a few themes that this trick wouldn't work on. Maybe if instead of @theme_selected_bg_color we used @selected_bg_color, might solve this? I know there's not a hard standard for variables (but one or two unofficial).

[DelD. (deldadam)]

Hi Michael,

> Most of this is intentional, actually.
:-(

> We essentially hardcoded this...
Never liked either the word 'hardcoded' or its meaning. :-(

This renders the selected desktop icons almost black on every dark themes, as it darkens further the color defined in the variable:
background-color: alpha(@theme_selected_bg_color, 0.8); (_IF_ the variable @theme_selected_bg_color defined at all! - see below)

> What theme is this occurring on?
I've tryed 'Jet-Gray' (http://cinnamon-spices.linuxmint.com/themes/view/489)
But to give you a more general definition: it occurs with every theme where the definition of the hardcoded "@theme_selected_bg_color" variable is missing. Oops. As soon as I put this into one of the CSS files:
@define-color theme_selected_bg_color @<whatever_color_you_want>;
...it starts to work.

> Maybe if instead of @theme_selected_bg_color we used @selected_bg_color, might solve this?
Maybe... But I'm not sure, as you don't know the value of @selected_bg_color and the hardcoded CSS rules would darken it more - which could result the same black (or almost black) icons on the desktop.

But I think the problem is:
- the hardcoded rules
- and the hardcoded rules are using (probably) not defined color variable @theme_selected_bg_color (as it is also hardcoded)

IMHO the issue could be solved a bit more 'intelligently'. I can fully understand and accept that we needed to do something, but it would be much usable solution if:
- we would use the '.nemo-desktop.nemo-canvas-item' rules (all of them!) defined in the theme if they exist
- and fall back to the hardcoded CSS rules if the theme doesn't define them

For example, in 'Jet-Gray' these rules are defined perfectly, but they don't work at all 'cos the hardcoded CSS rules overwrite them.

Using the 'fall-back' technique we wouldn't waste days to figure out why our lovely theme doesn't work despite of our (or the selected theme's) humble attempt to follow GTK specs and Cinnamon docs.

Of course, I have to admit as I'm not a dev. guy, and I don't know whether my 'intelligent' solution is doable. But a 'not-so-intelligent' solution would be at least to inform the theme makers or create a website (or update the docs) or whatever to make your infos publicly available, in order to give a chance for ppl. like me and others (like above) to figure out what's wrong.

Anyway, thank you for your answer. It helped me a lot!

[Michael Webster (miketwebster)]

Your suggestion makes a lot of sense, and indeed we actually wish it worked this way (we've tried it - this isn't a new issue :))

Check out this bug report I filed with GTK a while back: https://bugzilla.gnome.org/show_bug.cgi?id=692379

My initial thoughts on the current situation, I'm considering either:

- Removing the color variable and hardcoding a simple outline

or

- Seeing if I can query the styled widget, and if the color there is #000000FF (black), try a different variable (theme_ or without as I mentioned in my previous post), and finally falling back on my first solution. Honestly this solution makes me slightly more uncomfortable than the first, as it's more complex (and more likely to break something down the road when gtk developers randomly change stuff) - as far as I can recall, there's no way to query 'does this name/style exist in the current theme?' - it silently applies it if it exists, or simply ignores it if not.

Being able to use the desktop trumps having the desktop match the theme, in our imaginary rulebook - we're pragmatic about things like this. I really love it when things are done right, and work right, and everyone is happy. But we're developing primarily for a distribution (Mint) so it needs to work, above all else. This sometimes means making some uncomfortable decisions and compromises.

[DelD. (deldadam)]

> ...indeed we actually wish it worked this way (we've tried it - this isn't a new issue :))
Somehow, I've guessed this will not be a 'straight to the heaven' march.

> Check out this bug report...
Bugs everywhere :) That's why the world will collapse very soon. (On the desktop, at least.:-)

Well, you have to know I'm not familiar with the ins and outs of GTK. But if a theme developer _always_ uses the variable @selected_bg_color (because it is compulsory), I would vote for the solution where your 'hardcode' would use this variable, as on this way it should/ought to work with most of the themes available (except for the themes with total black backgrounds - but hey, they are black, after all!).

But it would be OK for me the simple outline as well - at least better than black icons. As - from the viewpoint of a 'rural' user - black spots on the screen always triggers the 'something is wrong here' feeling. I've spent many hours (actually days!) to find the reason of this issue, and seen hundreeds of suggestions on forums, websites. One of the poor guy was instructed to remove the nVidia driver, and reinstall everything (including updates in repos for devs/testing - ouch).

> Honestly this solution makes me slightly more uncomfortable than the first, as it's more complex...
I concur. As soon as it gets more complex, it is bound to collapse sooner. (My extension for Murphy's law.)

My last tought on this. If you can't check whether a style or name exist, can't you check whether a color _variable_ does exist? (I bet this has occured to you, too.)