Bug 360237 - Breeze draws window frame in Window:BackgroundNormal for both active and inactive windows
Summary: Breeze draws window frame in Window:BackgroundNormal for both active and inac...
Status: RESOLVED INTENTIONAL
Alias: None
Product: Breeze
Classification: Plasma
Component: window decoration (show other bugs)
Version: 5.5.95
Platform: Compiled Sources Linux
: NOR minor
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-08 01:33 UTC by Jon Griffiths
Modified: 2016-03-10 02:20 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Griffiths 2016-03-08 01:33:01 UTC
I am overriding the colors of windows using _KDE_NET_WM_COLOR_SCHEME. In my colors file I set WM/activeBackground and WM/inactiveBackground and the title bar uses these colors when active/inactive as expected.

However the border of the window is always drawn using Colors:Window/BackgroundNormal regardless of whether the window is active or inactive. This looks bad and is non-intuitive. I believe:

- In most/all cases the frame color should be the same as the title, or
- If that is not possible/desirable then it should be possible to specify an inactive color for the frame.
- The WM decoration would ideally only use colors from the [WM] section.

Ideally this use of color would be the same for all default provided themes (esp Oxygen) as well.
Comment 1 Jon Griffiths 2016-03-08 01:40:02 UTC
This can be tested from konsole using a sample colors file and xprop. Given a colors file /tmp/red.colors containing:

[Colors:Window]
BackgroundNormal=255,0,0

[WM]
activeBackground=255,0,0
inactiveBackground=128,0,0

Then the konsole colors can be set by running:

xprop -f _KDE_NET_WM_COLOR_SCHEME 8s -set _KDE_NET_WM_COLOR_SCHEME /tmp/red.colors

and clicking on the konsole window. Observe that following this, the window frame remains bright red when the window loses focus even though the title darkens.
Comment 2 Hugo Pereira Da Costa 2016-03-08 07:51:22 UTC
Hi,
Thanks for reporting. 

The fact that the decoration borders blends into the main window and that only the titlebar has the decoration active/inactive color has been a design choice for breeze since the very beginning. See for instance how the outlining "blue" line, at the top, for active windows, would not make any sense if we were coloring all sides. 
It is not clear to me what is "unintuitive" about that.
For Oxygen, the original design choice was even stronger that the full decoration should blend into the window, for both color and window gradient, on the premise that the separation between window content and window decoration is artificial, and that the WM colors would be ignored all-together. 
Since this created lots of complain, an option was introduced (and recently re-added for the KF5 version) to oxygen to use the active WM color for the decoration. For the comming plasma release you just need to uncheck "Use the same color for titlebar and window content" in the oxygen decoration config dialog.

Bottomline:
- for breeze the current situation wont change, sorry
- for oxygen, there is an option that allows you to achieve what you want, I think
- the third window decoration that is shipped with plasma by default (plastique) does what you want out of the box I think

best, 

Hugo
Comment 3 Jon Griffiths 2016-03-10 02:20:14 UTC
(In reply to Hugo Pereira Da Costa from comment #2)

Hi Hugo, thanks for your prompt and detailed reply.

The context behind this issue is that KDE/Kwin is used by Qubes O/S as its domain 0 UI. In order to enhance user security, frame and title color are used to indicate the domain (level of trust) of the VM executing each X11 app. Qubes wants to move to a later KDE version and retain this functionality which is currently provided by a custom hacked 4.x plastik plugin.

Since the decoration API was changed in KF5, and is currently both internal and under flux, its not really possible to build out of tree C++ decorations anymore. In the Qubes case we would need to change internal interfaces (to expose VM details through the X native window) even if we could build an out of tree decoration of our own. So at least until the decoration API stabilizes we are looking at a simpler solution and _KDE_NET_WM_COLOR_SCHEME gives us 99% of what we need with no KDE code changes required.

> It is not clear to me what is "unintuitive" about that.

From your explanation, knowing the look and feel goals of each decoration, it seems intuitive, I agree. However from the point of view of styling these decorations its unintuitive to me because the color names used by each decoration are different. So I can't style oxygen and breeze using the same .colors file, the colors that look right for breeze make oxygen look bad, because the meaning of them has changed ('window background' means 'frame color' to breeze but 'frame color and title color' to oxygen).

In my ideal world, I would set colors under [WM] only, to change what the WM draws with, and where a decoration wants to use the same colors as the window it would either expect them as [WM] elements with the same colors, or at least prefer the [WM] element and fall back to the Colors:Window element only if not present under [WM].

So for example, oxygen would use the WM active/inactive title colors to paint the title - they just would both be either set to the window background color by default, or if not present, fall back to it.

Both breeze and oxygen would use WM:BackgroundNormal/BackgroundInactive to paint the frame color, or fall back to their default of the window background.

In this way, the decoration can be styled by changing the WM elements only. If they aren't set, or are set to the same values as the backup colors then nothing visibly changes. But I can set one colors file and reliably change the frame/title color regardless of the current decoration. That is to me the whole point of having a [WM] colors section in the first place.

> an option was introduced (and recently
> re-added for the KF5 version) to oxygen to use the active WM color for the
> decoration.

I will experiment with this, we will probably enable this by default. Thanks for letting me know about it.

> - the third window decoration that is shipped with plasma by default
> (plastique) does what you want out of the box I think

My investigation with this is that changing the colors in this way has no effect at all under KF5 plastik. But for our initial purposes oxygen and breeze will be fine. It would just be nice if they could be colored in a consistent way.