https://bugs.kde.org/show_bug.cgi?id=428322
--- Comment #11 from Mikhail Zolotukhin <zom...@protonmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
