When kwin starts for the first time, it uses the wrong color scheme. This is because it does not monitor creation of ~/.config/kdeglobals, which is just https://phabricator.kde.org/D22238 again. To reproduce: rm ~/.config/kdeglobals dbus-run-session kwin_x11 --replace systemsettings5 # change the color scheme Currently I'm thinking this was introduced by fbab964e983eebc03a87f0099640eee957d0c728, but some changes elsewhere made this race on startup more likely.
Actually, it seems like it doesn't even monitor changes to kdeglobals. So the rm ~/.config/kdeglobals isn't even needed. Maybe the switch to KConfigWatcher broke that?
This is because we haven't yet shipped a kconf update script to switch current users of the Breeze color scheme over to Breeze light, rewrite the colors in kdeglobals. We will do this before 5.21 is tagged.
(In reply to Nate Graham from comment #2) > This is because we haven't yet shipped a kconf update script to switch > current users of the Breeze color scheme over to Breeze light, rewrite the > colors in kdeglobals. We will do this before 5.21 is tagged. Would that also explain that just "kwin_x11 --replace" after login makes it work again? kdeglobals only contains color schemes after kconf_update ran. I don't know which .upd file does that (yet). It seems like KConfigWatcher doesn't actually watch for file content changes, but rather just for DBus events. I assume that kconf_update somehow misses to emit those.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/50
It goes deeper! Kwin only cares about the "expanded" color scheme in kdeglobals. It does not read [General] ColorScheme at all, neither in ~/.config/kdeglobals nor from the look-and-feel. The only reason this worked previously is because the kde4breeze (!) kconf_update script expands the color scheme from the look-and-feel into ~/.config/kdeglobals and kwin had a QFileSystemWatcher on that. The missing piece here is that kde4breeze does not use KConfigBase::Notify and so KConfigWatcher doesn't react. On top of that, kconfig had a bug and it ignored KConfigBase::Notify there. Fix for kde4breeze: https://invent.kde.org/plasma/breeze/-/merge_requests/50 Fix for kconfig: https://invent.kde.org/frameworks/kconfig/-/merge_requests/32 With those merged, kwin uses the look-and-feel's color scheme on first login again. What remains to be fixed is that kwin reads the proper color scheme name itself (like plasma-integration does) and kconf_update has to use KConfigBase::Notify throughout.
Git commit 2f68c5427c4a1643018b9a41bff2c83e50c5a03f by Fabian Vogt. Committed on 07/11/2020 at 14:36. Pushed by fvogt into branch 'master'. Fix KConfigGroup::copyTo with KConfigBase::Notify Without this, bNotify was not set on copies, making Notify a noop. M +4 -0 src/core/kconfig.cpp https://invent.kde.org/frameworks/kconfig/commit/2f68c5427c4a1643018b9a41bff2c83e50c5a03f
Git commit 8d491add52589cb8af5f7f4392e14f5d464ca6fd by Fabian Vogt. Committed on 12/11/2020 at 09:15. Pushed by fvogt into branch 'master'. Notify on color scheme changes kde4breeze changes the color scheme when it runs as part of kconf_update, but at that time some applications (including kwin) might already be running. Those need to be notified of the change. M +1 -1 misc/kde4breeze/src/main.cpp https://invent.kde.org/plasma/breeze/commit/8d491add52589cb8af5f7f4392e14f5d464ca6fd
Git commit a632f35e49f1475618557790328a498c32bc4f90 by Fabian Vogt. Committed on 12/11/2020 at 11:29. Pushed by fvogt into branch 'Plasma/5.20'. Notify on color scheme changes kde4breeze changes the color scheme when it runs as part of kconf_update, but at that time some applications (including kwin) might already be running. Those need to be notified of the change. (cherry picked from commit 8d491add52589cb8af5f7f4392e14f5d464ca6fd) M +1 -1 misc/kde4breeze/src/main.cpp https://invent.kde.org/plasma/breeze/commit/a632f35e49f1475618557790328a498c32bc4f90