SUMMARY Automatic theme switching mostly does work, but the panel and its associated widgets will get stuck in the opposite color scheme when the session is ended (via shutdown, restart, or logout) before the transition is completed. Windows are set to the proper color scheme. The effect basically looks like Breeze Twilight, but my color schemes are Breeze Light and Breeze Dark, respectively. Restarting plasma-kded6 temporarily fixes the problem, until the cycle restarts. STEPS TO REPRODUCE 1. Enable automatic day-night theme switching 2. Wait until theme transition begins 3. End the session before the transition completes OBSERVED RESULT Upon login, windows are the proper color scheme, the panel and its widgets are not EXPECTED RESULT Both the windows and the panel and its widgets should be the same, proper color scheme based on the day/night cycle SOFTWARE/OS VERSIONS Operating System: EmilicOS Linux KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Graphics Platform: Wayland Graphics Processor: AMD Radeon Graphics
Can you please clarify steps to reproduce? So, say the transition starts at 6:00PM and ends at 6:30PM, if you reboot somewhere between 6:00-6:30PM, your computer is stuck with the wrong theme until the next transition?
(In reply to Vlad Zahorodnii from comment #1) > Can you please clarify steps to reproduce? So, say the transition starts at > 6:00PM and ends at 6:30PM, if you reboot somewhere between 6:00-6:30PM, your > computer is stuck with the wrong theme until the next transition? Sorry for the miscommunication, this is a bit of a difficult one to explain. Anyway, you are correct. If the transition begins at 6:00PM and ends at 6:30PM, if I reboot at any point before the transition is complete, the panel and its applets will remain in the light theme, while windows will correctly use the dark theme. Let's say the day-night transition begins at 6:00PM. I shut down my computer at 6:28PM. I boot my computer again at 7:00PM, the panel and its applets will have the light theme, while windows will have the dark theme.
Created attachment 189485 [details] Example of broken ui, half breeze dark half breeze light
I'm experiencing the same behavior. It occurs when I suspend the laptop at night and then wake it up in the morning. STEPS TO REPRODUCE: 1) Suspend the system while the dark theme is active. 2) Wake up the system after the scheduled hours when the light theme should be applied. Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.8-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700U with Radeon Graphics Memory: 40 GiB of RAM (37.0 GiB usable) Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82KU System Version: IdeaPad 3 15ALC6
*** Bug 517598 has been marked as a duplicate of this bug. ***
*** Bug 519292 has been marked as a duplicate of this bug. ***
I'm marking this CONFIRMED, since a couple of other users have run into this.
*** Bug 520550 has been marked as a duplicate of this bug. ***
*** Bug 521500 has been marked as a duplicate of this bug. ***
I can reproduce the issue as described.
(In reply to Nate Graham from comment #10) > I can reproduce the issue as described. Nice
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/234
I don't know if this helps but my workaround is setting up the day/night shift manually by time. By doing so I don't encounter the bug with mixed themes.
*** Bug 521730 has been marked as a duplicate of this bug. ***
Just in case, I used to see this issue too. But after adding relevant qDebug()s in plasma-integration (I suspect that plasmashell somehow misses global theme changes) and plasma-workspace, I don't encounter it anymore. :/
> I suspect that plasmashell somehow misses global theme changes Because new windows (e.g. config dialogs) of plasmashell still use the dark color scheme, while dolphin and other apps use the light color scheme.
*** Bug 521918 has been marked as a duplicate of this bug. ***
(In reply to greening.felony from comment #13) > I don't know if this helps but my workaround is setting up the day/night > shift manually by time. By doing so I don't encounter the bug with mixed > themes. Attempted this on my system, unfortunately I still have this issue. Your mileage may vary, though.
*** Bug 522274 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6815
Git commit 06098adfb08a051cbe96ff411bf73de15b204382 by Vlad Zahorodnii. Committed on 02/07/2026 at 11:20. Pushed by vladz into branch 'master'. qt6: Skip loading palettes when widget style changes This is rather to make sense from the current code. The widget style loads the system palette but it doesn't determine whether the color scheme is light or dark like other code paths. When the color scheme changes, we should receive a org.kde.KGlobalSettings.notifyChange broadcast event with the PaletteChanged type, so the widget style should be unnecessary. M +0 -1 qt6/src/platformtheme/khintssettings.cpp https://invent.kde.org/plasma/plasma-integration/-/commit/06098adfb08a051cbe96ff411bf73de15b204382
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/236
Git commit f818743d0cb4225b633c487827c23eb74f8e80cd by Vlad Zahorodnii. Committed on 02/07/2026 at 12:05. Pushed by vladz into branch 'Plasma/6.7'. qt6: Skip loading palettes when widget style changes This is rather to make sense from the current code. The widget style loads the system palette but it doesn't determine whether the color scheme is light or dark like other code paths. When the color scheme changes, we should receive a org.kde.KGlobalSettings.notifyChange broadcast event with the PaletteChanged type, so the widget style should be unnecessary. (cherry picked from commit 06098adfb08a051cbe96ff411bf73de15b204382) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +0 -1 qt6/src/platformtheme/khintssettings.cpp https://invent.kde.org/plasma/plasma-integration/-/commit/f818743d0cb4225b633c487827c23eb74f8e80cd
Git commit 54df28956a5ed4240afcc913b6ad6c3f60f43fd3 by Vlad Zahorodnii. Committed on 02/07/2026 at 17:04. Pushed by vladz into branch 'master'. startkde: Log the global theme that gets applied This is to help with debugging the issues with automatic global theme autoswitching. M +1 -0 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/54df28956a5ed4240afcc913b6ad6c3f60f43fd3
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6818
Git commit 1e181942abcbf96621b0262259bd0404c7d53999 by Vlad Zahorodnii. Committed on 02/07/2026 at 17:48. Pushed by vladz into branch 'Plasma/6.7'. startkde: Log the global theme that gets applied This is to help with debugging the issues with automatic global theme autoswitching. (cherry picked from commit 54df28956a5ed4240afcc913b6ad6c3f60f43fd3) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +1 -0 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/1e181942abcbf96621b0262259bd0404c7d53999
I tested this the same way I did before, and can confirm that it's now fixed! Thanks Vlad.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6842
(In reply to Nate Graham from comment #27) > I tested this the same way I did before, and can confirm that it's now > fixed! Thanks Vlad. Unfortunately, I don't think the issue is fully fixed yet. I found a very likely culprit why this bug happened.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6844
Git commit 4a2bf4d8369a265fa00048ab7973a8e0ef1485ea by Vlad Zahorodnii. Committed on 15/07/2026 at 10:20. Pushed by vladz into branch 'master'. kcms/color: Update ColorSchemeHash startplasma attempts to apply the color scheme in the global theme. It avoids applying the color scheme again by saving the hash of the current color scheme. This creates an issue with automatic global theme switching. For example, consider the following case: - the user starts their computer during daylight (the hash of the corresponding color scheme is A) - the user continues using their computer without rebooting until the global theme is changed to the dark flavor. This will apply the dark color scheme (its hash is B, but it's not written to ColorSchemeHash) - the user turns off their computer at night - then the user starts the computer in the morning. startplasma sees that the light global theme needs to be applied. It then attempts to apply the color scheme. startplasma looks at the hashes and they match (A == A). However, that is wrong, the effective applied color scheme has hash B. This change fixes the issue by making the applyScheme() function also write the hash of the currently applied color scheme. Our long term goal is to stop updating kdeglobals, but we are not there yet. M +11 -0 kcms/colors/colorsapplicator.cpp M +1 -0 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/4a2bf4d8369a265fa00048ab7973a8e0ef1485ea
Git commit 47342d073878125dfbd4c27bd9768dffeeb48f0c by Vlad Zahorodnii. Committed on 15/07/2026 at 11:29. Pushed by vladz into branch 'Plasma/6.7'. kcms/color: Update ColorSchemeHash startplasma attempts to apply the color scheme in the global theme. It avoids applying the color scheme again by saving the hash of the current color scheme. This creates an issue with automatic global theme switching. For example, consider the following case: - the user starts their computer during daylight (the hash of the corresponding color scheme is A) - the user continues using their computer without rebooting until the global theme is changed to the dark flavor. This will apply the dark color scheme (its hash is B, but it's not written to ColorSchemeHash) - the user turns off their computer at night - then the user starts the computer in the morning. startplasma sees that the light global theme needs to be applied. It then attempts to apply the color scheme. startplasma looks at the hashes and they match (A == A). However, that is wrong, the effective applied color scheme has hash B. This change fixes the issue by making the applyScheme() function also write the hash of the currently applied color scheme. Our long term goal is to stop updating kdeglobals, but we are not there yet. (cherry picked from commit 4a2bf4d8369a265fa00048ab7973a8e0ef1485ea) M +11 -0 kcms/colors/colorsapplicator.cpp M +1 -0 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/47342d073878125dfbd4c27bd9768dffeeb48f0c
*** Bug 523823 has been marked as a duplicate of this bug. ***