GNOME Bugzilla – Bug 771831
[3.22.x][CSS] Embedded "@theme_fg_color" causes incorrect label colour on user-themes
Last modified: 2016-09-25 00:02:33 UTC
Dear Developers, I'm an author of Adapta Gtk+ theme (https://github.com/tista500/Adapta), then I've seen new 3.22.x style-sheet (dconf-editor.css), And I've experienced some regressions outside the Adwaita Gtk+ theming. [Reporter Info] Gtk+ version: 3.22.0 Distribution: Ubuntu GNOME 16.10 Desktop Environment: Gnome-Shell 3.22.0 [Cases] #1. Embedded @theme_fg_color linking is only suitable in case if Gtk+ themes had "light variant" GtkHeaderBar (headerbar node) on light-variant. For example, my Adapta, Arc, Numix, Paper, Flat-Plat, Ambiance, and much themes has "dark variant" headerbar node on light-variant. And usually we set theme_fg_color in _colos_public.scss as "dark foreground-color on light-variant". So could it be possible to switch to: /* ensure label color */ .pathbar > button > .item, .pathbar > button:disabled > .item { - color:@theme_fg_color; + color: currentColor; } .pathbar:backdrop > button > .item, .pathbar:backdrop > button:disabled > .item { - color:@theme_unfocused_fg_color; + color: alpha(currentColor, 0.5); } If those could be accepted, we can override those label.item style-class's color property from user-themes. #2. the style-class label.item.root-button has ":disabled" pseudo-class when those are under ":checked"? I think underline-indicator should be used in :checked pseudo-class instead of :disabled class. Isn't it caused unwanted label fading in Adwaita? Once I've switched form @theme_fg_color to currentColor with patchworks, surely underlined label node's foreground was toned down in Adwaita (looks like mixed with background-color?). Finally actual issue is #1 for me (and many of theme designers, too). I really hope this could be fixed... Best Regards.
Thanks for reporting these interesting bugs. #1. Your patch completely breaks the color logic (same color for all buttons), that applies badly to Adwaita & Adwaita:dark & HighContrast (my usual targets), and I don’t see any good reason to go that way; so, just “no” to that one. Anyway, I see your problem and I do agree that it would be great for gtk+ to handle themes with dark headerbar and light colors elsewhere when needed; but I think that’s a problem that should be reported and handled inside gtk+ itself, even if I don’t know if that should be done with special CSS classes, or with a settings property, or with other named colors. If you see a not-completely-hacky way to fix in dconf-editor’s code your problem, without breaking the three official gtk+ themes, I could accept it. Else, you probably will have to use the “.dconf-editor” CSS target (applied to the window) to fix whatever you want from your theme. #2. Using the Gtk+ Inspector (do you use it?), in the “CSS Nodes” entry in the “Objects” combobox, I don’t see anything that’s ever “:checked” there. But I spotted a difference between the root button and the other buttons: the focus-on-click property was set to “false” to the first and not-set defaulting to “true” for the others. I corrected that in commit 615649b64 [1].Could that be what is causing you a problem? Else, please, reexplain/screencast. [1] https://git.gnome.org/browse/dconf-editor/commit/?id=615649b64e6a9ebff0a273a8f4c000772e602b69
Created attachment 336115 [details] CSS inspector Really? Please see my shot with CSS inspector -> object -> CSS node. The parent button node of selected .root-button style-class has :disabled pseudo-class already. I thought this is why you've added such label node colouring in CSS, am I wrong? Regards.
:disabled are used in "insensitive" state, so I don't understand why "selected"(:checked) state was under insensitive state. Since 99% themes are usually going to set insensitive foreground as fading (or low brightness) colours. I suppose if those :disabled pseudo-class turned to :checked class, label foreground settings in CSS were not needed. Regards.
Right, there’s a semantically incorrect use of CSS states, that is the root cause of your problems. I’ll try to fix this, even if it’ll complexify the code quite more than I’d want.
I now confirmed this issue was solved and can be closed. Thanks !! :) Best regards.
Great! Many thanks for having reported this issue. There are things that would need to be changed for the pathbar if Adapta was the official theme, but I don’t find a way to make better for now, keeping Adwaita as my main target. You can use the .dconf-editor CSS target to make changes from your theme, if you want. I have seen one more problem: go (for example) to /ca/desrt/dconf-editor/demo/boolean and change “use default value”; appears at the bottom an actionbar. If you have a big window, you see an “Apply” button; but if you reduce the size of your window, this button becomes an image button (yay! responsive design), and… disappears: “actionbar button.image-button.suggested-action” is written white on more-or-less-white. Something forgotten on your side?
(In reply to Arnaud B. from comment #6) > Great! Many thanks for having reported this issue. > > There are things that would need to be changed for the pathbar if Adapta was > the official theme, but I don’t find a way to make better for now, keeping > Adwaita as my main target. You can use the .dconf-editor CSS target to make > changes from your theme, if you want. > Yes, I've already added specifc theming before I've reported bugzilla. > I have seen one more problem: go (for example) to > /ca/desrt/dconf-editor/demo/boolean and change “use default value”; appears > at the bottom an actionbar. If you have a big window, you see an “Apply” > button; but if you reduce the size of your window, this button becomes an > image button (yay! responsive design), and… disappears: “actionbar > button.image-button.suggested-action” is written white on > more-or-less-white. Something forgotten on your side? Confirmed now. This is because Adapta specific issue that was the conflict of "@at-root button.suggested-action" and "actionbar button.image-button". In Adapta, .image-button was enforced to be "flat" styling without any raised background and shadows in actionbar. So transparentized background and @theme_selected_fg_color was shown as "white-on-white" missing button, I think... This conflict was fixed by my commit: https://github.com/tista500/Adapta/commit/5f529721f95ed110225d07c6ad6fc17a43ac5da3 Thanks for your info!! :)