KWin5 and colour scheme special application setting (the case of the WM menus)

René J.V. Bertin rjvbertin at
Fri Mar 17 09:01:15 GMT 2017

On Friday March 17 2017 05:48:36 Duncan wrote:

Replying with CC to the plasma-devel list as this appears to be relevant:

>> Something I didn't yet notice: KWin doesn't seem to respect the setting
>> when I restart the application. It's still there, and applied when I
>> click through the app settings dialog. As if the application name isn't
>> set properly when I start Spotify and KWin thus doesn't detect it.

>I didn't say earlier, but I don't use spotify (which AFAIK is a 
>So I can't try with that specific app.
>However, FWIW, the window rule action for titlebar colorscheme is fairly 
>new, and from what I can tell, still very bugged-out/broken.  It's 
>effectively broken here.  It appears to do nothing, and most of the time, 
>it resets to breeze no matter what I tried to reset it to.  And even tho 
>it says breeze and that's not my default, it doesn't seem to do anything 
>-- it doesn't change it from the custom scheme that /is/ my default.
>I'd say that's because I'm running live-git and that functionality is 
>broken ATM, but if so, it has been broken thru several releases now, ever 
>since I noticed the setting and tried it the first time.  It just doesn't 
>seem to work.

>So if you've gotten it to change a titlebar to some non-default color 
>scheme at all, as it seems you have, you've gotten farther with it than 
>I've managed to accomplish.

Yes, I can confirm that it will apply the selected colourscheme at least partly.

I think I can understand how this is non-trivial. KWin runs as a single application so it cannot use QGuiApplication::setPalette() to change a colour palette and let Qt take care of applying the palette everyhere. Not at least if only a single window is to be changed.
Come to think of it, with the way menus and menu actions are reused in KDE software it's not surprising that the WM menu doesn't follow a window's non-standard palette entirely. What does surprise me though is the fact that the menu action text does change, but not the background. Context menus are often generated on the fly when they're needed but even then often reuse QActions. In that case you'd expect the menu background to follow the local palette, but the items to use the global palette.


More information about the kde mailing list