After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756803 - Nautilus File Operations icon in top bar hard to see in alternative Dark GTK Themes
Nautilus File Operations icon in top bar hard to see in alternative Dark GTK ...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Main Toolbar
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-19 09:30 UTC by Harrison Pace
Modified: 2015-10-27 10:30 UTC
See Also:
GNOME target: ---
GNOME version: 3.17/3.18


Attachments
File Operations on Dark GTK Theme (86.10 KB, image/png)
2015-10-19 09:30 UTC, Harrison Pace
  Details
a patch to fix the issue (1.23 KB, patch)
2015-10-21 10:07 UTC, eyelash
needs-work Details | Review

Description Harrison Pace 2015-10-19 09:30:48 UTC
Created attachment 313647 [details]
File Operations on Dark GTK Theme

The default Adwaita GTK Theme is fairly light in colour, and as a result the new File Operations Dialogue introduced in Gnome 3.18 has a dark colour scheme. This is fine for any light theme, however on Dark Themes where the colour of the GTK Top Bar is black, the File Operations becomes very hard to see or invisible. 

This would be fine if themes could modify the Colour of this Icon and the File Operations Animation, but this is not possible using standard themes. The colour of the Top Bar thus should not be Hard Coded and should be adjustable by Dark Themes such as Ark. 

Reference to this Bug is noted here as experienced by the Arc Developer: https://github.com/horst3180/Arc-theme/issues/258 - This includes an image of the referenced behaviour. 

An image of the described Behaviour is also attached. 




**This is the first bug I have posted in Gnome Bug Tracker, please advise if I have handled incorrectly**
Comment 1 Carlos Soriano 2015-10-20 08:38:31 UTC
Your bug report is correct, thanks!

It's not in my personal priority list (for now), but I would like to have it fixed.
Comment 2 Carlos Soriano 2015-10-20 08:42:45 UTC
-> gnome-love, should be easy to fix taking a color from the nautilus css theme instead of hardcode it.
Comment 3 eyelash 2015-10-21 10:07:54 UTC
Created attachment 313794 [details] [review]
a patch to fix the issue

This is my first real patch so I'm not yet familiar with all the rules
Comment 4 Carlos Soriano 2015-10-21 11:52:00 UTC
Review of attachment 313794 [details] [review]:

::: src/nautilus-toolbar.c
@@ +671,3 @@
+        gtk_style_context_get_color (style_context, gtk_widget_get_state_flags (widget), &foreground);
+        background = foreground;
+        background.alpha *= 0.3;

It's a nice solution I didn't think about. However, this doesn't fix the issue to all themes. Maybe for them 0.3 alpha doesn't look right. Instead, write a custom css style class in the custom nautilus css and get the color from it. Then 3rd party themes can override those.
Comment 5 eyelash 2015-10-25 18:56:04 UTC
Unfortunately I don't have the time for a more complicated solution and frankly I don't believe it is needed. In my patch I tried to follow the way symbolic icons are drawn. Please correct my if I'm wrong but neither is there a way to set a secondary colour from the theme for symbolic icons.
Comment 6 Carlos Soriano 2015-10-26 15:38:55 UTC
(In reply to user142 from comment #5)
> Unfortunately I don't have the time for a more complicated solution and
> frankly I don't believe it is needed. In my patch I tried to follow the way
> symbolic icons are drawn. Please correct my if I'm wrong but neither is
> there a way to set a secondary colour from the theme for symbolic icons.

There is no way for a second color in symbolic icons, so we assume correctly foreground should have enough contrast in the theme regarding the background color.
However, what you are doing here is creating a new color with foreground.alpha * 0.3, which symbolic icons does not use (if I'm not mistaken of course), and that new color is hardcoded, and could be problematic for other themes where backgrund and foreground are close enough than 0.3 alpha could be a problem for contrast for them.

My proposal is simply adding a class in src/Adwaita.css and take the color from it for both the icon foreground (which I expect to be the same as theme foreground color) and then icon backgrund that could be different than foregrund.alpha * 0.3.

But since your solution is not a hack and is already better than what we have, let's go with that and if someone with such problem is interested they can provide a patch.

Thanks for it!
Comment 7 Carlos Soriano 2015-10-26 16:51:09 UTC
Pushed to master and gnome-3-18
Comment 8 Carlos Soriano 2015-10-26 17:01:24 UTC
And I don't know why git bz didn't work properly, here's the commit:
https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-18&id=4c9d1b2acc49b19f9d9225ea419078f444d763ae

Thanks again Elias!
Comment 9 eyelash 2015-10-26 19:02:55 UTC
Thanks for pushing :)

BTW there are indeed symbolic icons that use a hardcoded alpha value (0.35 in this case):

https://git.gnome.org/browse/adwaita-icon-theme/tree/Adwaita/scalable/status/audio-volume-low-symbolic.svg
Comment 10 Carlos Soriano 2015-10-27 10:30:07 UTC
(In reply to eyelash from comment #9)
> Thanks for pushing :)
> 
> BTW there are indeed symbolic icons that use a hardcoded alpha value (0.35
> in this case):
> 
> https://git.gnome.org/browse/adwaita-icon-theme/tree/Adwaita/scalable/status/
> audio-volume-low-symbolic.svg

ah! Thanks for the pointer!