Created attachment 141665 [details] Screenshot illustrating the issue with Konsole SUMMARY In Breeze Dark, menubar and toolbar colour is not following window titlebar background colour changes when switching when windows are changing to active / inactive. STEPS TO REPRODUCE 1. Select Breeze Dark theme. 2. Open two application windows with menubar and / or toolbar. 3. Switch windows to active / inactive. OBSERVED RESULT Titlebar background colour changes, but menubar / toolbar background does not follow along. EXPECTED RESULT Titlebar, menubar and toolbar background change consistently with active / inactive window state. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.11-gentoo (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION See attached screenshot.
Hmm, that is not expected. This works for me. What widget theme are you using? And can you paste the [Colors:Header] and [Colors:Header][Inactive] sections of your ~/.config/kdeglobals file?
With Widget Theme, You mean the Application Theme in systemsettings5? This is "Breeze" in my case, while the Plasma Style is "Breeze Dark" as well. For "Window Decorations", it's Breeze. Here are the sections from kdeglobals: [Colors:Header] BackgroundAlternate=42,46,50 BackgroundNormal=49,54,59 DecorationFocus=61,174,233 DecorationHover=61,174,233 ForegroundActive=61,174,233 ForegroundInactive=161,169,177 ForegroundLink=29,153,243 ForegroundNegative=218,68,83 ForegroundNeutral=246,116,0 ForegroundNormal=252,252,252 ForegroundPositive=39,174,96 ForegroundVisited=155,89,182 [Colors:Header][Inactive] BackgroundAlternate=49,54,59 BackgroundNormal=42,46,50 DecorationFocus=61,174,233 DecorationHover=61,174,233 ForegroundActive=61,174,233 ForegroundInactive=161,169,177 ForegroundLink=29,153,243 ForegroundNegative=218,68,83 ForegroundNeutral=246,116,0 ForegroundNormal=252,252,252 ForegroundPositive=39,174,96 ForegroundVisited=155,89,182
I can also not reproduce on a KDE Neon live system. Copying over kdeglobals from my system also does not cause this issue to show up. However, in KDE neon I notice there is a slight delay after the titlebar is recolorized (from activation / deactivation) to the menubar / toolbar following along, so there seems to be a two-step process. Maybe my issue is not a color scheme issue, but an issue with triggering this recolorization? Does this require a specific minimum Qt version, or something which is only in the Qt5PatchCollection? Gentoo currently ships Qt 5.15.2-r3, which does not yet include the patches from the Qt5PatchCollection. Work to integrate them is ongoing, though: https://bugs.gentoo.org/806797
That Qt version should be fine; I don't think that feature is tied to the Qt version. Very strange issue. Not caused by the colors in the color scheme and not an issue in the decoration theme; issue is somewhere in the QStyle, or caused by an unknown local issue on the affected machine.
(In reply to Oliver Freyermuth from comment #3) > Gentoo currently ships Qt 5.15.2-r3, which does not yet include the patches > from the Qt5PatchCollection. Work to integrate them is ongoing, though: > https://bugs.gentoo.org/806797 That's in stable, but testing already contains all the relevant Qt5PatchCollection snapshots going to be stabilised soon.
(In reply to Andreas Sturmlechner from comment #5) > That's in stable, but testing already contains all the relevant > Qt5PatchCollection snapshots going to be stabilised soon. Thanks! Indeed, I am running stable — I've updated to the freshly stabilized Qt packages now (which include Qt5PatchCollection), and the issue remains. So this is indeed not due to Qt5PatchCollection patches missing.
I have now upgraded to KDE Frameworks 5.88.0, and the issue persists. Switching the colour scheme to something else and back does not change the issue. Other ideas welcome.
I am also experiencing this issue, it has been like that for a while I think but I only really noticed it now. For me it happens on both Breeze Light and Breeze Dark, however if I create a new user the bug doesn't appear there, so I wonder if there's some old piece of config somewhere that could cause the issue (my main install and user account is about 3.5 years old by now, and I was also running GNOME, LXQt, dwm and sway at some point throughout those 3.5 years). SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530
I also tried the Flatpak version of Dolphin and it does not exhibit the bug, and it's on the same system and same user account that normally experiences the bug with Dolphin from the Arch repos.
I'm now on Plasma 5.24.2 and Frameworks 5.91.0, and the issue appears to have resolved itself somehow.
(In reply to Prajna Sariputra from comment #10) > I'm now on Plasma 5.24.2 and Frameworks 5.91.0, and the issue appears to > have resolved itself somehow. Thanks, that makes me hopeful for when these versions are marked as stable on Gentoo (they are already in the repositories, but not stabilized yet). Concerning the issue, it would of course be ideal in case we'd find the causing or fixing commit to allow for potential backports to LTS distros.
It looks like you have the side window borders enabled; the new style only applies when the borders option in the Window Decorations KCM is set to "No Borders" or "No Side Borders"
Indeed.
Wow, thanks for catching this! This made my day, or maybe even my week :-). I can confirm disabling side borders (or all borders) fixes this issue, I was unaware enabling the tiny borders (which I did many Plasma versions ago) would have such an effect Now my only remaining issue with the new design is #435905, but that's a different bug. Thanks!
(In reply to Jan Blackquill from comment #12) > It looks like you have the side window borders enabled; the new style only > applies when the borders option in the Window Decorations KCM is set to "No > Borders" or "No Side Borders" Ah, yes I did switch that to follow the theme defaults recently, didn't make the connection. Although then if it's intentional for the new style to apply with no (side) borders only, why do Kirigami apps use the new style regardless? Would that be a bug on the Kirigami end, or is that also intentional somehow? The reason this caught my eye at all was the inconsistency between the Kirigami and QtWidget based apps.