https://bugs.kde.org/show_bug.cgi?id=360237
--- Comment #3 from Jon Griffiths ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
