KDE5 decoration plugin #1784

Open
marmarek opened this Issue Feb 26, 2016 · 31 comments

Projects

None yet

5 participants

@marmarek
Member

KDE 5 have major changes in window decoration plugin API, making upgrade hard. Most likely Qubes decoration plugin will need to be rewritten from scratch.

This issue blocks dom0 upgrade to something newer than Fedora 20.
We're planning to add Gnome support in dom0, which somehow makes this issue lower priority, but still an issue.

Related discussion: https://groups.google.com/d/msgid/qubes-devel/20150708225129.GN900%40mail-itl

@marmarek marmarek added this to the Release 4.0 milestone Feb 26, 2016
@jgriffiths

As discussed on the list, here is a diff to the current kwin master (git://anongit.kde.org/kwin) that displays the VM title as a suffix on every window, regardless of the current decoration style.

@jgriffiths

And here is a program to demonstrate the palette setting option. compile with gcc propset.c -lX11 -o propset and run on a KF5 box with breeze windows decorations (the default) as e.g.:

./propset _KDE_NET_WM_COLOR_SCHEME /usr/share/color-schemes/Zion.colors
./propset _KDE_NET_WM_COLOR_SCHEME /usr/share/color-schemes/Norway.colors

If we were to install schemes with label suffixes then xside.c could set this property to point to the files and no further KWin changes would be required!

@jgriffiths

The following is a minimal color profile that will be applied by KWin:

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

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

According to the KDE color scheme docs at https://docs.kde.org/trunk5/en/kde-workspace/kcontrol/colors/index.html (look for 'Window Manager Colors'), its up to the theme whether they use the window manager colors from the [WM] section or the Window colors.

Experimentation shows that Breeze uses WM/activeBackground/inactiveBackground while Oxygen uses [Colors:Window]/BackgroundNormal (Oxygen doesn't seem to dim the window if its not active). Its not clear what Plastik is using.

You can try the above with the propset test program and see that the colors are correct under Oxygen and Breeze. Given this I'm going to hack up a patch to xside.c to set this value.

@jgriffiths

And here is a commit making gui-daemon set the palette file for KWin.

@jgriffiths

Finally, here is a quick script to generate sample palette files for all VMs. Placed in /usr/share/qubes/color-schemes with the patch above applied they should provide window colors under both oxygen and breeze.

@marmarek
Member

And here is a program to demonstrate the palette setting option.

There is a standard utility xprop.

@jgriffiths

Fixed gui-daemon range checking, updated commit is here.

I didn't realise xprop let you set properties too, doh.

@marmarek
Member
marmarek commented Mar 6, 2016

Can you post some screenshots how it looks? With custom color palette and VM name as remote machine name, different themes etc.

@marmarek
Member
marmarek commented Mar 7, 2016

I've tried this on Fedora 23 Live.
The mechanism for setting border colors looks to be just fine. Technically, I think color scheme should be named like qubes-VMNAME and generated for each VM (either at VM startup, or creation). To not repeat the mistake of hardcoding color values in one more place. QubesVmLabel objects know appropriate RGB value.

But I've failed to get VM name in the window title. WM_CLIENT_MACHINE seems to be ignored, at least when set on already existing window. Does it work for you?

@jgriffiths

The VM name will only show in the window with the kwin patch linked above applied, then _QUBES_VMNAME set via xprop. WM_CLIENT_MACHINE won't work and if it did we couldn't use it anyway I think. We have to keep all existing methods/markers of truly remote windows intact.

Setting the VM name using that patch works with all windows decorations though, and its a very small patch to carry compared to the current plugin.

I will attempt to get some screenshots up shortly.

@jgriffiths

See http://postimg.org/image/vu4vxue49/ and http://postimg.org/image/n1sinwid5/ - these show a patched kwin5 + breeze with VM name and colors set manually using xprop.

Note that 1) the colors aren't correct (either by rgb value or label-to-color mapping) since this is just a mock up and 2) the kwin patch doesn't format the VM name in any way so I manually set it to ' [vmname]'.

However you can see that the active/inactive colors change when windows are selected which is nice I think.

@marmarek
Member
marmarek commented Mar 7, 2016

Setting the VM name using that patch works with all windows decorations though, and its a very small patch to carry compared to the current plugin.

Yes, it is small, but still it requires carrying own kwin package - tracking upstream version etc. Compared to the plugin which worked almost untouched across multiple KDE and Fedora versions. But if there is no other way...

Or maybe there is: if no formatting is applied to the VM name anyway, maybe gui-daemon can simply prefix window title with "[VMNAME]"? That should be some configuration/command line option to easily switch this feature on different window managers, or when someone will implement better support for KDE.

However you can see that the active/inactive colors change when windows are selected which is nice I think.

Yes :) Apparently only title bar is changed, not the rest of the window borders, which looks a little weird, but not a problem.

@jgriffiths

maybe gui-daemon can simply prefix window title with "[VMNAME]"?

If this covers all the ways in which apps can set their title then it seems like a good idea as an initial implementation.

Apparently only title bar is changed, not the rest of the window borders, which looks a little weird,

Yeah, that looks like a kwin bug TBH and I'm pretty sure upstream will accept a patch for it. Until its fixed upstream, picking a smaller difference in active/inactive colors than my test color files would look better.

@marmarek
Member
marmarek commented Mar 7, 2016

If this covers all the ways in which apps can set their title then it seems like a good idea as an initial implementation.

Yes, this is the only way how VM can set a window title visible in title bar (where currently it is prefixed with VM name by window manager). There are some cases where window don't have title bar at all (for example tray icons), but there is no place for VM name either.

@jgriffiths

Great, would you like me to code this up for the gui-daemon with a command line option to enable it?

@marmarek
Member
marmarek commented Mar 7, 2016

Yes :)

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

@jgriffiths

I've added untested/uncompiled support for this to this branch.

Compiling and testing is proving difficult due to qubes-builder breakage which I'll raise on qubes-devel. My worry currently is what happens if a program fetches its own window title and then appends something to it, will it end up with the VM name prefix twice?

@jgriffiths

I've raised a KDE Bug for the window frame color issue, lets see what upstream have to say about it.

@jgriffiths

OK, I've built and trivially tested the branch and it seems to work as far as the title goes.

Regarding your comments on naming the color files after the VM I don't think its a good idea, I think they should be named after the levels. I suspect if we want to support multiple VM decorations that we will end up with a set per decoration, e.g. red-breeze, red-oxygen etc (because each decoration uses different and incompatible color elements from the file).

@marmarek
Member
marmarek commented Mar 8, 2016

I suspect if we want to support multiple VM decorations that we will end up with a set per decoration, e.g. red-breeze, red-oxygen etc (because each decoration uses different and incompatible color elements from the file).

Isn't it possible to have them in the same file? I think your generator does exactly that, no? Anyway, if not, we can have qubes-work-breeze, qubes-shopping-oxygen etc. That would also require adding another option to gui-daemon for choosing that suffix (regardless if that would be red-breeze or qubes-work-bereeze).

Additionally (not sure about that), it may be possible then to switch border colors on the fly, without restarting VM. Depends on KDE - if/when color profile is reloaded. Pretty minor feature, but if we'd got it for free, why not?

Anyway, thanks for the patches! I'll try get back to fc22 based dom0 somehow later this week (need to find which disk it was...). After final R3.1 release, which is building just now :)
If you want to help further with upgrading dom0, I've just added build instructions to #1807

@jgriffiths

Isn't it possible to have them in the same file?

If you read the response to the KDE bug, the upstream view seems to be that its up to each window decoration to use whatever colors they feel like in actually drawing the window. For breeze we can make the colors look good by setting the border (Colors:Window:BackgroundNormal) to the inactive color (i.e. a slightly darker shade) so when the window activates the title brightens and it darkens when inactivated (this looks much better than the screenshots above where the border color stays bright when deactivated).

But since oxygen only uses Colors:Window:BackgroundNormal for both the border and the title, we have to set it to the actual label color when using the oxygen style. Under oxygen we get no choice to dim the color for inactive windows. We can't therefore use a single color file and have both styles looking their best. Other default styles and default theme styles can presumably be tweaked using different color override still.

we can have qubes-work-breeze, qubes-shopping-oxygen etc.

Yes this is doable and I suspect the only approach if you want per vm color files instead of per label. These could be handled in the same way as the VM icon file is from the looks of it, generated from qvm-create with an external helper that imports the color definitions and spits out color files for the styles we support into the VM directory.

If you want to help further with upgrading dom0, I've just added build instructions to #1807

Yes I am looking forward to playing with this, thanks.

I will also be looking at other areas as I get used to the code, I imagine there are a few areas I may be able help out.

@m-v-b
m-v-b commented Apr 11, 2016

As an alternative/interim solution, I customized the Breeze theme, as can be seen at marmarek/qubes-desktop-linux-kde@c57ef7d and marmarek/qubes-desktop-linux-kde#1

@marmarek marmarek modified the milestone: Release 3.2, Release 4.0 Apr 28, 2016
@marmarek marmarek added P: blocker and removed P: major labels Apr 28, 2016
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016
@marmarek marmarek kde-baseapps: update based on Fedora 23 version 8a9e3a5
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016
@marmarek marmarek plasma-breeze-qubes: use Obsoletes instead of Conflicts
This is better for upgrade.

QubesOS/qubes-issues#1784
468a164
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016
@marmarek marmarek qubes-menus: add symlink for KDE5 cdc6b70
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016
@marmarek marmarek kde-settings: update based on Fedora 23 package
This is preliminary update of kde-settings package, not all
Qubes-specific customzations are migrated yet.

QubesOS/qubes-issues#1784
c2e6898
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016
@marmarek marmarek kde-settings: hide Thunar file manager if installed
It isn't strictly KDE component, but lets hide it from KDE menu.

QubesOS/qubes-issues#1784
ea308a1
@marmarek
Member
marmarek commented May 4, 2016 edited

Status update: pushed fedora-23 branch to my repo. It contains modified breeze decoration and some preliminary update of other packages (kde-settings, kde-baseapps etc).
Customization not migrated yet:

  • set default wallpaper
  • set menu button icon
  • disable user switch feature
  • set breeze theme by default
  • remove "Places" section from "Computer" tab in the menu (or "Computer" tab at all)
  • remove device notifier applet
@marmarek marmarek added a commit to marmarek/qubes-gui-daemon that referenced this issue May 9, 2016
@marmarek marmarek Add an option for custom window properties
Allow specify custom X11 properties to be added to each windows of a VM.
This can be used to configure window manager - for example use native
configuration to set colorful frames (_KDE_NET_WM_COLOR_SCHEME).

QubesOS/qubes-issues#1784
d8efb65
@marmarek marmarek added a commit to marmarek/qubes-gui-daemon that referenced this issue May 9, 2016
@marmarek marmarek Option to prefix window titles with VM name
Prefix window titles with VM name in square brackets (like "[vmname]
title"). Normally this is done by customized window decoration plugin.
Just another option to better support non-customized window managers.

QubesOS/qubes-issues#1784
88dae41
@marmarek
Member
@marmarek
Member

After some more thinking and playing with patched breeze theme, I've switched back to native theme and @jgriffiths approach with custom color there. This looks to be much easier to maintain.

@marmarek
Member

Additional problem: tray icons do not have colorful border, and generally are quite ugly. I'm under impression that icon there isn't actual VM window embedded into panel (as it should be according to System Tray Protocol Specification), but some icon manually extracted by KDE and drawn there (after some manipulation?). Also tooltip of that icon is a window title ([sys-net] NetworkManager Applet), not the actual tooltip of nm-applet icon (current network name, signal strength).

And one more: automatic screen dimming after inactivity does work, but restoring original brightness have huge delay (like 20 sec or even more). It may be totally unrelated KDE bug.

@marmarek
Member

And one more: automatic screen dimming after inactivity does work, but restoring original brightness have huge delay (like 20 sec or even more). It may be totally unrelated KDE bug.

It looks like the issue have gone after recent KDE update.

@marmarek marmarek added a commit to marmarek/old-qubes-core-admin that referenced this issue May 18, 2016
@marmarek marmarek core: adjust guid parameters when running on KDE5
On KDE5 native decoration plugin is used and requires special properties
set (instead of `_QUBES_VMNAME` etc).
Special care needs to be taken when detecting environment, because
environment variables aren't good enough - this script may be running
with cleared environment (through sudo, or from systemd). So check
properties of X11 root window.

QubesOS/qubes-issues#1784
94d52a1
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 18, 2016
@marmarek marmarek plasma-breeze-qubes: drop modified theme and just generate color palete
Using upstream theme with custom color palete requires even less
maintenance, so is preferred solution. Additionally this way both title
bar and borders are colored.

Initial script implemented by @jgriffiths (thanks!), later modified to
dynamically extract defined labels and color values.

QubesOS/qubes-issues#1784
a967410
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 18, 2016
@marmarek marmarek kde-settings: include patched kickoff applet
Remove "Computer" tab.
kickoff.tar.gz is unmodified upstream version.

QubesOS/qubes-issues#1784
b200ffc
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 18, 2016
@marmarek marmarek qubes-kde-dom0: update dependencies for Plasma ef3d212
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 18, 2016
@marmarek marmarek qubes-kde-dom0 5.12.3, kde-baseapps 15.12.3-2, kde-settings 23-12, qu…
…bes-menus 1.2-1

QubesOS/qubes-issues#1784
49d9582
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 18, 2016
@marmarek marmarek qubes-kde-dom0 5.12.3, kde-baseapps 15.12.3-2, kde-settings 23-11.1, …
…qubes-menus 1.2-1

QubesOS/qubes-issues#1784
880d939
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 19, 2016
@marmarek marmarek qubes-kde-dom0: update dependencies for reduced breeze theme 311ff86
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 19, 2016
@marmarek marmarek qubes-kde-dom0 5.12.3, kde-baseapps 15.12.3-2, kde-settings 23-11.1, …
…qubes-menus 1.2-1

QubesOS/qubes-issues#1784
c1848da
@marmarek
Member

Additional problem: tray icons do not have colorful border, and generally are quite ugly. I'm under impression that icon there isn't actual VM window embedded into panel (as it should be according to System Tray Protocol Specification), but some icon manually extracted by KDE and drawn there (after some manipulation?). Also tooltip of that icon is a window title ([sys-net] NetworkManager Applet), not the actual tooltip of nm-applet icon (current network name, signal strength).

Created #2042 for this.

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 7, 2016
@andrewdavidwong andrewdavidwong Track #1784 4bd40de
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue Jun 7, 2016
@marmarek marmarek qubes-kde-dom0: provide default desktop applets configuration
I can't manage to remove devicenotifier using config init/update API
(https://userbase.kde.org/KDE_System_Administration/PlasmaTwoDesktopScripting),
so provide default configuration file in /etc/skel.

QubesOS/qubes-issues#1784
036bc06
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue Jun 7, 2016
@marmarek marmarek qubes-kde-dom0: set default wallpaper 79bd8d5
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue Jun 7, 2016
@marmarek marmarek qubes-kde-dom0: set default menu button icon ca35ab0
@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 12, 2016
@andrewdavidwong andrewdavidwong Update #1784 e493d24
@marmarek marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue Jun 25, 2016
@marmarek marmarek plasma-breeze-qubes: fix autostart settings for palette generator
There should be semicolon at the end. Also remove NoDisplay=true to make
debugging easier.

QubesOS/qubes-issues#1784
Reported by: Niels Kobschaetzki <niels@kobschaetzki.net>
ba3bd78
@marmarek marmarek added a commit to QubesOS/qubes-desktop-linux-kde that referenced this issue Jun 25, 2016
@marmarek marmarek plasma-breeze-qubes: fix autostart settings for palette generator
There should be semicolon at the end. Also remove NoDisplay=true to make
debugging easier.

QubesOS/qubes-issues#1784
Reported by: Niels Kobschaetzki <niels@kobschaetzki.net>
f706917
@rootkovska rootkovska added P: minor and removed P: blocker labels Jun 30, 2016
@andrewdavidwong
Member

In light of the move from KDE to Xfce4 as the default in R3.2, is anyone still working on still working on this? In particular, @jgriffiths? Asking for tracking purposes.

@jgriffiths

I'm not working on this right now, I've recently started a new job which is taking most of my time.

Also I think its time to admit that KDE has lost the plot with constant refactoring and chasing non desktop usage. It is ugly, slow and unstable. I would stop using Qubes if it forced gnome in dom0 but I can live with xfce. Especially if I can upgrade dom0 past f22 sooner as a result.

@andrewdavidwong
Member

Understood. Thanks.

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jul 31, 2016
@andrewdavidwong andrewdavidwong Update #1784 status 132da6d
@marmarek marmarek added a commit to marmarek/old-qubes-core-admin that referenced this issue Sep 8, 2016
@marmarek marmarek qubes/ext/gui: adjust guid parameters when running on KDE5
Commit from core2:

    commit 94d52a1

    core: adjust guid parameters when running on KDE5

    On KDE5 native decoration plugin is used and requires special properties
    set (instead of `_QUBES_VMNAME` etc).
    Special care needs to be taken when detecting environment, because
    environment variables aren't good enough - this script may be running
    with cleared environment (through sudo, or from systemd). So check
    properties of X11 root window.

    QubesOS/qubes-issues#1784
19d9edc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment