SUMMARY STEPS TO REPRODUCE 1. Change GTK theme in SystemSettings to some non-standard one (Yaru, Materia, whatever) 2. Open some GTK app 3. Observe icons mess in the app's header bar. OBSERVED RESULT Breeze icons struggling with another theme's ones for a place under the sun. EXPECTED RESULT Headerbar icons *should* follow theme's settings. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.20.1 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION It has been happening since Plasma 5.20.0 Removing of ~/.config/gtk-3.0/window_decorations.css helps, but only until user sets another GTK theme in SystemSettings.
Created attachment 132781 [details] Screenshot of the affected application
What's the contents of your ~/.config/gtk-3.0/gtk.css?
Hi Mikhail, It's just 2 strings: @import 'colors.css'; @import 'window_decorations.css';
This is strange. You should only have "import colors" string. I cannot reproduce this bug, but I'll investigate. The thing is it's explicitly said in the code to remove the import statement when changing the theme to non-Breeze one. If nothing helps, I might want to tell the code to remove window decorations css file as well just to be sure.
OK I decided to delete the entire ~/.config/gtk-3.0 directory, and now gtk.css behaves as expected: when Breeze is selected, it contains "@import 'window_decorations.css'", when some other theme -- there's no such line. Thanks for a hint how it's coded, I think it had something to do with old configs' leftovers in that folder (there were several extra files there compared to what's there now).
OK so it's back after reboot. "@import 'window_decorations.css';" string appeared again. Buttons are messed up again. This is really weird.
Some good meows: now I can reproduce this bug, so in the free time I will look into it more deeply and probably find a way to fix it.
I find a more precise way to reproduce bug: 0. Do not open GTK app yet. 1. Open GTK page, set GTK theme to Breeze. 2. Open GTK app. 3. At this moment change the GTK theme in settings 4. Now the decorations are broken. However, the decoration changing behavior is ok if you do these actions: 5. Close the GTK app and open it again. 6. Decorations are normal now (the ones are from the GTK theme you've selected) 7. Change the GTK theme to Breeze and then again to another theme. TLDR: decorations are broken only if your initial (i.e. is selected in the settings, when you open a GTK app) theme is Breeze. Otherwise, (when the initial theme is another one), there should be no glitches, when changing the themes back and forth. Please confirm if the behavior is same for you as I described.
Yes, now it is exactly the way you described it. However, I had to remove .config/gtk-3.0 directory before the above became true. That also disclosed another hidden bug, which is when a user sets Breeze for the first time (and when no gtk-3.0 dir exist yet) such GTK Breeze theme ignores system colors set in Systemsettings. I had green correctly applied to Breeze before, but for now it is a regular "dark header + light window + blue selections" Breeze look. And it affected the look of other themes like Materia. Of course I am able to re-apply colors again, my goal here is just to add some extra observations. So, I confirm things you said. Also I want to note how I discovered the bug: when changing Application Style from, say, Kvantum to Breeze, Breeze GTK theme applies to GTK apps automatically. Initially this was the point where broken headers were discovered.
Yep I can confirm with those steps, Mikhail.
I think I found the bug's source and the solution. The thing is that current Breeze GTK CSS customization is based on two sources: CSS provided by gtk.css file, that is in the `~/.config/gtk-3.0/` folder and the CSS file that can be loaded and unloaded dynamically via GTK module - window_decorations.css. This approach has some caveats. First, it will not fully work with GTK 4, because the latter dropped support for modules (i.e. extensions to GTK4). Because of that this bug will be reproducible in more conditions. Second, it basically has a conflicting way of loading CSS into GTK applications. GTK apps by default (i.e. without modules) has two sources of CSS: system theme, selected in GTK Settings Page (gtk.css is located in `/usr/share/themes`) and the user defined CSS (located in `~/.config/gtk-3.0/gtk.css`). With the module we can load CSS files literally from anywhere in our file system. What we are doing now is relaying on the built-in GTK functionality to load CSS from `.config` folder and also on the custom functionality of KDE written module to load and unload the CSS when the application is running. This bug happens because GTK initially loads the gtk.css from the `.config` with the decorations CSS and then, when the user is changing the theme, we ask our KDE module to unload the decorations CSS. But our module have nothing to unload, because it is not the one who loaded the CSS file and it does not know the pointer to the CSS provider from `.config`. (CSS provider is the GTK code structure to manipulate the CSS of applications). I haven't found the way to get the pointer to CSS provider for the `.config` CSS, so I have found another solution. What we should do is drop gtk.css in the ~/.config directory completely (or at least for window decorations, as we are using it for colors syncing, that does not break apps' appearance at least) and make the module responsibility loading window_decorations.css dynamically including loading it on the initialization step of the module. This should simplify the code base and fix the bugs. This would however mean, that decorations' appearance syncing will not work with gtk4 apps at all until we found a way to make it to so. Also, since the module must be written in C, we need to find some alternative way to watch GTK theme changing (perhaps monitoring the settings.ini file?). I think it's a reasonable trade off.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/17