KWin5 and colour scheme special application setting
1i5t5.duncan at cox.net
Sun Mar 19 08:35:46 GMT 2017
Duncan posted on Fri, 17 Mar 2017 05:48:36 +0000 as excerpted:
> 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 just chanced to figure out what /part/ of the problem was, here!
While I believe it's a bug in the window-rules settings dialog that keeps
resetting it to breeze under normal conditions, and I didn't figure out
any more information about /that/ bug...
The reason I used the "most of the time" wording above, was that under
some as yet not completely figured out conditions, perhaps including
leaving the dialog /without/ actually hitting apply, the window-rule
titlebar color scheme action /would/ actually stick and be the same when
I returned to it, tho it didn't seem to actually make any difference.
What I just chanced to figure out, because in my experiments for this
thread I left the color scheme on the window rule for one of my commonly
used windows set to something entirely different than my normal scheme
despite it not appearing to actually work...
... is that it /was/ actually working.
I just wasn't seeing it due to my selection of the plastik window
decoration, which apparently doesn't have the quirk in it that allows the
titlebar (itself, the actual titlebar) colorscheme to be set differently
for different apps. While (unlike the oxygen decoration, which appears
to use the inactive titlebar color for both active and inactive) the
plastik decoration does actually change the active and inactive titlebar
colors to match the global color scheme, it forces all titlebars to the
same global scheme, not allowing for kwin to set individual titlebars to
a different colorscheme, as the breeze decoration (for instance) does.
So I wasn't seeing any changes in the titlebars themselves because of the
But apparently I hadn't actually opened a titlebar window menu at the
appropriate time to notice that despite the titlebar itself not changing
color due to the plastik decoration not supporting that, the window menu
*WAS* actually changing color to match the rule.
After having left the window rule color scheme setting set to something
wild, eventually (just now!) I chanced to open the window menu for that
titlebar, and despite the titlebar not changing color due to the plastik
decoration apparently not supporting that, the window menu color *WAS*
So it /was/ working, I just hadn't seen it.
After figuring out that the menus were showing up changed even if the
titlebar itself wasn't, right away I realized it must be the window
decoration I was using that prevented me from seeing the setting in the
window titlebar itself. So I quickly went to the window decorations
setting and tried switching to breeze. Sure enough, as soon as I did,
the drastically different color scheme I had set for that window actually
And... with a bit more checking, I verified that indeed, with breeze set
as the window decoration, both the menu background and foreground colors
were that of the specified for that window titlebar colorscheme. Same
with plastik; altho it didn't actually change the titlebar color, it
/did/ change both the background and foreground menu colors. And with
the oxygen decoration, it changed both foreground and background menu
colors, as well as changing the titlebar color (to the inactive color
even when active, since that's all it uses).
So what elements actually get changed do indeed appear to depend on the
window decoration. You mentioned qtcurve as your widget style, but I
don't see what window decoration you're using. Presumably, whatever it
is only honors the menu text setting, while keeping the default menu
background, just as oxygen seems to use inactive titlebar color for both
active and inactive, while honoring both menu colors, and plastik honors
both the menu colors but still uses the default titlebar colors. Only
breeze seems to honor all four elements, active and inactive titlebar
colors, and foreground and background menu colors, for the window-rule
selected titlebar color scheme instead of the global color scheme.
Meanwhile, now that I figured that out, I have to go try to figure out
how to get that window's titlebar colorscheme setting back to default...
Actually wasn't too hard as I could just uncheck the setting there, I
didn't have to actually figure out what the bug is that keeps the setting
from changing schemes most of the time when I'm actually trying to do
that, and work around it.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde