[Breeze] [Bug 428771] Default color scheme not changes until manually modified or a new account is created
https://bugs.kde.org/show_bug.cgi?id=428771 --- Comment #6 from Fabian Vogt --- 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-0src/core/kconfig.cpp https://invent.kde.org/frameworks/kconfig/commit/2f68c5427c4a1643018b9a41bff2c83e50c5a03f -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 428771] Default color scheme not changes until manually modified or a new account is created
https://bugs.kde.org/show_bug.cgi?id=428771 --- Comment #5 from Fabian Vogt --- 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. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 428771] Default color scheme not changes until manually modified or a new account is created
https://bugs.kde.org/show_bug.cgi?id=428771 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #4 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/50 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 428771] Default color scheme not changes until manually modified or a new account is created
https://bugs.kde.org/show_bug.cgi?id=428771 --- Comment #3 from Fabian Vogt --- (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. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 428771] Default color scheme not changes until manually modified or a new account is created
https://bugs.kde.org/show_bug.cgi?id=428771 Nate Graham changed: What|Removed |Added Summary|Kwin uses wrong color |Default color scheme not |scheme on first start |changes until manually ||modified or a new account ||is created -- You are receiving this mail because: You are watching all bug changes.
