KDE decoration plugin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

We've been working on dom0 update for some future Qubes version (3.1 or
3.2) to some more recent Fedora version (22, or even 23), which brings
many updates - most notably KDE 5. The problem is that it changes
decoration plugin API and our decoration plugin is no longer working
there (actually it doesn't even compile...). Does anyone have some
experience in KDE 5/Qt 5? We're seeking for help here.

The plugin code is here:
https://github.com/QubesOS/qubes-desktop-linux-kde/tree/master/plastik-for-qubes
It is based on "plastik" plugin, which looks to be here in the new KDE code
base:
https://projects.kde.org/projects/kde/workspace/kwin/repository/revisions/master/show/clients/aurorae/themes/plastik

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVnalxAAoJENuP0xzK19cso1UH/RKD6zgkZi9SeXhtujx3vWLP
qK3h0wrCjLvD+ooBPjSB+VYErwZ+vxe6Qh74wJCFJTFoWSZBfvauqdJpN0Y5S2gs
x5gZ5t2OTQZVjgHk7ex9WQXCGhXMXKRoor/zRpGdD3cD41v61DJ4YyJ+v1qsgPbp
/npd1j+GDmddcskZ/r0UAdZPSqmrzvw5AsgpDssQHZa64JWkraXy9iNXFdjeBm5Y
tI0pzl6wVkYaKBPa1CSq81mxAkAG4suSDOHlzNGdEzITYWQQJd420NvkK36XzD46
MD8hnRYbvijfarti/cnVWf4C+FCoyLNrDw7zPGCAeGuP9swaiqioNBArNUPn900=
=IlEc
-----END PGP SIGNATURE-----

[cprise]

On 07/08/2015 06:51 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> We've been working on dom0 update for some future Qubes version (3.1 or
> 3.2) to some more recent Fedora version (22, or even 23), which brings
> many updates - most notably KDE 5. The problem is that it changes
> decoration plugin API and our decoration plugin is no longer working
> there (actually it doesn't even compile...). Does anyone have some
> experience in KDE 5/Qt 5? We're seeking for help here.
>
> The plugin code is here:
> https://github.com/QubesOS/qubes-desktop-linux-kde/tree/master/plastik-for-qubes
> It is based on "plastik" plugin, which looks to be here in the new KDE code
> base:
> https://projects.kde.org/projects/kde/workspace/kwin/repository/revisions/master/show/clients/aurorae/themes/plastik
>
> - --

I suggest creating an entry at kde-apps.org so you can attract attention
directly from the KDE community.

[Outback Dingo]

On Thu, Jul 9, 2015 at 2:38 PM, cprise <cpr...@gmail.com> wrote:

On 07/08/2015 06:51 PM, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

We've been working on dom0 update for some future Qubes version (3.1 or
3.2) to some more recent Fedora version (22, or even 23), which brings
many updates - most notably KDE 5. The problem is that it changes
decoration plugin API and our decoration plugin is no longer working
there (actually it doesn't even compile...).  Does anyone have some
experience in KDE 5/Qt 5? We're seeking for help here.

The plugin code is here:
https://github.com/QubesOS/qubes-desktop-linux-kde/tree/master/plastik-for-qubes
It is based on "plastik" plugin, which looks to be here in the new KDE code
base:
https://projects.kde.org/projects/kde/workspace/kwin/repository/revisions/master/show/clients/aurorae/themes/plastik

Super Nice, Fedora 22, with XEN 4.5.1 and KDE Plasma 5..... Would completely ROCK as a Qubes Desktop.

 

- --

I suggest creating an entry at kde-apps.org so you can attract attention directly from the KDE community.

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/559DFAD8.7090307%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jeremias E.]

Hello,

what exactly does the KDE decoration plugin?
Is it just responsible for the "qubes" menu on the
desktop and the generation of the submenus?

Is it additionally responsible for the window handling?
Unspoofable windows manager?

Best regards
  J. Eppler

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The only think it does it making window frames colorful matching to VM
label, and sticking VM name into title bar.

Other parts are handled by configuration of standard KDE components.

- --
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?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQEcBAEBCAAGBQJWzeh6AAoJENuP0xzK19cs4EkH/AuBDC9kwkKWkFj/zWpZO5Ry
cn2QQ0cVyFBHhCAW7rd2qaQw3JqHp57M6w2hHKvffxDLCDpiywJXsga4ITwUvbIl
nkQK7JZbt+VzrazIhPreRTg3MzQDEWlwZQaBznaXjCiZQ2UrJiSwcuitpk2DOrcI
hvytYYyB7rlzEc6OSabcLTBHjJ1ct4PAsZ6w93lfTi4lEbrsMrgvk6VgfbFo4Pi7
n4C9QfxVtiZXJ7mwuYvAHaR8yWO+G6vbmTqhJB2Dt0kJQjMOfvpyF4KSicJthPBU
iNtt+CIyhSYUaYMJfP23AeRJ6TgTHkgvH3eYUoHItlIR93LWB13Jcpq8ZLsBp20=
=vztc
-----END PGP SIGNATURE-----

[Eric Shelton]

On Wednesday, February 24, 2016 at 12:29:45 PM UTC-5, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Feb 23, 2016 at 08:08:55PM -0800, Jeremias E. wrote:
> Hello,
>
> what exactly does the KDE decoration plugin?
> Is it just responsible for the "qubes" menu on the
> desktop and the generation of the submenus?
>
> Is it additionally responsible for the window handling?
> Unspoofable windows manager?

The only think it does it making window frames colorful matching to VM
label, and sticking VM name into title bar.

Other parts are handled by configuration of standard KDE components.

I wanted to point out that this is a small, discrete project where someone with the right skills (KDE 5/Qt 5 development experience) - or someone interested in putting forth the effort to learn the necessary frameworks - could, probably without too much effort, make a contribution that has a significant effect for the Qubes project.  It does not require the knowledge of Xen or Qubes internals needed to engage in other development projects.  As I understand it, this is the main thing keeping dom0 back on Fedora 20, which in turn leads to its own issues, including lagging support for newer hardware (particularly GPUs).

Eric

[Jon]

On Thursday, February 25, 2016 at 11:34:32 AM UTC+13, Eric Shelton wrote:

I wanted to point out that this is a small, discrete project where someone with the right skills (KDE 5/Qt 5 development experience) - or someone interested in putting forth the effort to learn the necessary frameworks - could, probably without too much effort, make a contribution that has a significant effect for the Qubes project.

I started looking into this a few days ago. There are very few people with any experience right now because the area has undergone/is undergoing large changes. The re-factored framework is not as amenable to Qubes needs as the old framework was. I will dump what I've discovered/been thinking so far in case anyone else is working on this (or thinking of starting). I'd be happy to discuss further if so.

The existing way of drawing decorations is to have all the drawing done in C++ called by the window manager with the drawing code having full access to the underlying X window. This was great from Qubes POV because data could be stashed in the X window and used to decorate it. Specifically, the code in gui-daemon/gui-daemon/xside.c which proxies windows to dom0 sets the window properties _QUBES_LABEL and _QUBES_VMNAME in the window. These are the label color and name of the VM respectively. The Qubes plastik plugin reads them from the window and sets the border color/ window title prefix accordingly.

The refactored system in KF5 is designed to decouple the X window from the decoration as far as possible and to promote the use of scripting to draw the decoration. One consequence of this design is that any property of the window that the decoration code wants to access must be exposed through a window managers 'client' interface which is static (doesn't support arbitrary runtime properties). This makes for a larger/more spread out diff than just changing the drawing code, and its unlikely that this code could be generalised enough to be taken upstream. The current version of the KF5 plastik code is very basic and only uses C++ for drawing buttons. Since its now a theme rather that a native decoration it cant be modified in the same way as before.

There are only 2 native decorations now, breeze and oxygen. Both unfortunately look worse than plastik, but they are better targets for adding this functionality to. It seems that no-one has managed to build an out of tree decoration plugin and even if they could, the code is bound to continue changing. IIRC the developers even advise against it. So we are probably stuck with maintaining a patch.

If we follow the existing approach then the task seems to be:

- Expose the 2 Qubes properties through the kwin client interface
- Pick a native decoration and hack it to use/obey the properties

This second part is a bit vague because I haven't looked into it in great detail yet. I have hacked up some code to expose a mock qubes property through the client interface and I've just recently got it to build - instructions for fedora are badly out of date and testing it is challenging. I also hacked the window title to append a mock domain to see what it looked like, and the result wasn't terrible. These little experiments are in the very early stages at present.

I wondered if there was a better way (or at least one with less friction) to implement what Qubes needs. I also wonder if we could allow more customisation of themes and/or even allow a choice of window decorations/label colors by the user (for color blind/visually impaired folks for example). If we could do this with minimum changes or changes that can be upstreamed then obviously that would be great.

Currently when displaying remote windows kwin appends the remote machine/session id to the window title. It seems to me that this remoting is basically what Qubes is doing, just with a different model and nomenclature of what a remote session is. Certainly we can hijack this functionality easily enough and append the VM name treating it like a machine name. The code to do that should be pretty minimal.

I like this idea because I think if we then went to the kwin devs and asked to be able to style the <machine name>, for example to bold it, wrap it in [], put it before the window title or whatever, we would have a good case for it or at least getting code that exposes this through the client interface accepted upstream. That would make any patch we have to carry smaller. It also means that we could change the plugins that we ship so that they highlight the machine name as an option. That could likely go upstream as well. Users could use any decoration plugin they wanted if they were happy with the plain formatting. If we follow the VM=remote model to its logical conclusion then the [dom0] label would disappear from window titles too (as non-remotes) - which I think would be more intuitive as well :-)

The second piece of the puzzle is the border coloring. While I was poking around the kwin code, I came across an old but potentially very interesting window property called _KDE_NET_WM_COLOR_SCHEME. This allows applications to set a color palette from a file for the windows decoration and appears to have been completely unused in the wild. I hacked up a program to set the property to point a local .colors file and at least under breeze it works to change the window border color . Full disclosure, it didn't under oxygen but I haven't investigated why. However for decorations that do respect the palette (or can be made to do so) this seems like a nice method, since it could allow e.g. the user to customise the rest of the palette/decoration, the desaturation for inactive windows, choose a high contrast/no green collection of palettes etc etc. Also, any changes or fixes made to better support this property would seem more likely to be accepted upstream.

There are of course other issues like forcing borders to be drawn, the system tray and task bar, and no doubt I'm still missing a lot of info/understanding. I will continue investigating and at some point I may reach out to the kwin devs to get their opinion/advice (I don't want to waste their time without a fuller understanding of the kwin code).

Perhaps raising an issue for this would be a good idea, so we can link any investigations/notes/experiments etc together.

Cheers
Jon

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Feb 26, 2016 at 04:24:20AM -0800, Jon wrote:
>
>
> On Thursday, February 25, 2016 at 11:34:32 AM UTC+13, Eric Shelton wrote:
>
> > I wanted to point out that this is a small, discrete project where someone
> > with the right skills (KDE 5/Qt 5 development experience) - or someone
> > interested in putting forth the effort to learn the necessary frameworks -
> > could, probably without too much effort, make a contribution that has a
> > significant effect for the Qubes project.
> >
>
> I started looking into this a few days ago. There are very few people with
> any experience right now because the area has undergone/is undergoing large
> changes. The re-factored framework is not as amenable to Qubes needs as the
> old framework was. I will dump what I've discovered/been thinking so far in
> case anyone else is working on this (or thinking of starting). I'd be happy
> to discuss further if so.

Thanks for detailed analysis of the problem!

> The existing way of drawing decorations is to have all the drawing done in
> C++ called by the window manager with the drawing code having full access
> to the underlying X window. This was great from Qubes POV because data
> could be stashed in the X window and used to decorate it. Specifically, the
> code in gui-daemon/gui-daemon/xside.c which proxies windows to dom0 sets
> the window properties _QUBES_LABEL and _QUBES_VMNAME in the window. These
> are the label color and name of the VM respectively. The Qubes plastik
> plugin reads them from the window and sets the border color/ window title
> prefix accordingly.

Exactly, very accurate description of the mechanism.

> The refactored system in KF5 is designed to decouple the X window from the
> decoration as far as possible and to promote the use of scripting to draw
> the decoration. One consequence of this design is that any property of the
> window that the decoration code wants to access must be exposed through a
> window managers 'client' interface which is static (doesn't support
> arbitrary runtime properties). This makes for a larger/more spread out diff
> than just changing the drawing code, and its unlikely that this code could
> be generalised enough to be taken upstream. The current version of the KF5
> plastik code is very basic and only uses C++ for drawing buttons. Since its
> now a theme rather that a native decoration it cant be modified in the same
> way as before.

Is 'theme' able to set anything on per-window basis (unlike the same for
every window)? Like some javascript or so? Or the only option for this
is going with native decoration?

> There are only 2 native decorations now, breeze and oxygen. Both
> unfortunately look worse than plastik, but they are better targets for
> adding this functionality to. It seems that no-one has managed to build an
> out of tree decoration plugin and even if they could, the code is bound to
> continue changing. IIRC the developers even advise against it.

What a pity... Out of tree decoration plugin for KDE 4 worked well for a
long time.
Does the same applies to themes (if answer to previous question is
positive)?

> So we are
> probably stuck with maintaining a patch.
>
> If we follow the existing approach then the task seems to be:
>
> - Expose the 2 Qubes properties through the kwin client interface
> - Pick a native decoration and hack it to use/obey the properties
>
> This second part is a bit vague because I haven't looked into it in great
> detail yet. I have hacked up some code to expose a mock qubes property
> through the client interface and I've just recently got it to build -
> instructions for fedora are badly out of date and testing it is
> challenging. I also hacked the window title to append a mock domain to see
> what it looked like, and the result wasn't terrible. These little
> experiments are in the very early stages at present.
>
> I wondered if there was a better way (or at least one with less friction)
> to implement what Qubes needs. I also wonder if we could allow more
> customisation of themes and/or even allow a choice of window
> decorations/label colors by the user (for color blind/visually impaired
> folks for example). If we could do this with minimum changes or changes
> that can be upstreamed then obviously that would be great.
>
> Currently when displaying remote windows kwin appends the remote
> machine/session id to the window title. It seems to me that this remoting
> is basically what Qubes is doing, just with a different model and
> nomenclature of what a remote session is. Certainly we can hijack this
> functionality easily enough and append the VM name treating it like a
> machine name. The code to do that should be pretty minimal.

That's a good idea. In fact VM name is something like remote machine
name :)

> I like this idea because I think if we then went to the kwin devs and asked
> to be able to style the <machine name>, for example to bold it, wrap it in
> [], put it before the window title or whatever, we would have a good case
> for it or at least getting code that exposes this through the client
> interface accepted upstream.

Does this means that "remote machine name" isn't exposed in that client
interface yet? Only already composed window title?
Can you paste a link for the client interface doc/spec/header, for
reference?

> That would make any patch we have to carry
> smaller. It also means that we could change the plugins that we ship so
> that they highlight the machine name as an option. That could likely go
> upstream as well. Users could use any decoration plugin they wanted if they
> were happy with the plain formatting. If we follow the VM=remote model to
> its logical conclusion then the [dom0] label would disappear from window
> titles too (as non-remotes) - which I think would be more intuitive as well
> :-)
>
> The second piece of the puzzle is the border coloring. While I was poking
> around the kwin code, I came across an old but potentially very interesting
> window property called _KDE_NET_WM_COLOR_SCHEME. This allows applications
> to set a color palette from a file for the windows decoration and appears
> to have been completely unused in the wild. I hacked up a program to set
> the property to point a local .colors file and at least under breeze it
> works to change the window border color . Full disclosure, it didn't under
> oxygen but I haven't investigated why. However for decorations that do
> respect the palette (or can be made to do so) this seems like a nice
> method, since it could allow e.g. the user to customise the rest of the
> palette/decoration, the desaturation for inactive windows, choose a high
> contrast/no green collection of palettes etc etc. Also, any changes or
> fixes made to better support this property would seem more likely to be
> accepted upstream.

In the worst case (or maybe not such bad?), decoration
plugin/theme/whatever can extract VM color from VM settings based on its
name. So having: a) VM name, and b) ability to run some code on per-window
basis would be enough.

But if there is simpler option (like reusing existing control for
decoration colors), of course it would be simpler to reuse them.

> There are of course other issues like forcing borders to be drawn

What do you mean by this? VM have very little control over window
properties, so advanced features like "border less dialog windows" or
such are out of VM control. Is there any situation where normal windows
get no border?

>, the
> system tray and task bar,

If standard "System Tray Protocol"[1] is still supported, it should just work. At
least in theory ;)

> and no doubt I'm still missing a lot of
> info/understanding.
>
> I will continue investigating and at some point I may
> reach out to the kwin devs to get their opinion/advice (I don't want to
> waste their time without a fuller understanding of the kwin code).
>
> Perhaps raising an issue for this would be a good idea, so we can link any
> investigations/notes/experiments etc together.

https://github.com/QubesOS/qubes-issues/issues/1784

[1]
https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW0FKbAAoJENuP0xzK19csqVAH/0jPtAhwPvn0PLC3ln/SwGon
Vfw/kAwPWTICuZqZNoCA0SylKFA+FncCBqKilys5qiuqPBFyheIxHz7HB04qR4kA
6S7Lqm/l0hbzM4SUnveQ8TfOH93JMwZS/1EAlIQn0LqpNOE3d1Ut5JK435eJfsMz
x6D+C9LTmTskKeR0hCPC1E8Q5nAgKsNEABGl2Kq/KqKmHE4t7G7rUxpa6jZ+xAWf
kLu+Xvu8EkAhYt8ia1NOCLdgK8JvxSZl8KdDkT7555Zc+Kf+9kiwu5Z7la0iQlkV
GNrzA9+pfQQmDGQ70OPShDCd3PJldOYjswjd9N5yb9J3sze8vuat3d0rgDVuhLg=
=EH27
-----END PGP SIGNATURE-----

[Jon]

On Friday, February 26, 2016 at 8:27:02 AM UTC-5, Marek Marczykowski-Górecki wrote:

    >Is 'theme' able to set anything on per-window basis (unlike the same for
    >every window)? Like some javascript or so? Or the only option for this
    >is going with native decoration?
     

Setting values from theme/plugin code is not useful as they don't have access to the raw X11 window, only the new client window abstraction. Decorations can only read the fixed set of values exposed by the window manager (isActive(), caption(), stuff like that).

Given your question here and below (and possible interest by others) I will try to describe the layout of the new KF5 system in a bit more detail. I'm still very new to this code so there may be small errors in my understanding - but the big picture should be correct.

First have a look at the high level wish list for the new decoration system at https://community.kde.org/KWin/Decoration. Note 'Remove Most of the Abilities' as one of the goals. The idea is that the decoration code should be decoupled from the raw window and have fewer responsibilities, with common requirements being shifted into framework code and provided once for all decorations.

Then you can read Martin (kwin/kdecoration developer) detail the actual implementation here: https://blog.martin-graesslin.com/blog/tag/kdecoration2/ (read the entries from the bottom up). The bottom entry there has a diagram which is useful, and it explains how the plugin code is now QObject based rather than being attached to an actual window.

The decoration code is now split between the KDecoration2, Kwin, Oxygen and Breeze projects under the workspace umbrella.

KDecoration2 is the library providing the base classes for deriving plugins from. The main class of interest is Decoration (https://lxr.kde.org/source/kde/workspace/kdecoration/src/decoration.h) which you derive from to make a new decoration. The decoration holds a DecoratedClient (https://lxr.kde.org/source/kde/workspace/kdecoration/src/decoratedclient.h) which is the interface that plugins get to query state from the window. It is very limited, e.g. the whole caption is available but not the remote name as a separate component. It does not allow setting and it is completely static (no runtime dynamic properties like _QUBES_LABEL are exposed). Note that while checking this info, I noticed a TODO to expose the window id via this interface, which while possibly useful, seems counter to the design - TBD.

If you want the decoration to be able to access a label and VM name, or even just a VM name then DecoratedClient must be extended. This class is pimpl'ed to DecoratedClientPrivate which is intended to abstract away the raw X11 window so that KDecoration2 can remain free of windowing system dependencies (e.g. a wayland client is underway). This private interface is extended by KWin to provide the implementation in DecoratedClientImpl (https://lxr.kde.org/source/kde/workspace/kwin/decorations/decoratedclient.h). Kwin also abstracts the actual client window away using AbstractClient (https://lxr.kde.org/source/kde/workspace/kwin/abstract_client.h) since it wants to have both X and wayland implementations. This means the abstract interface must be changed as well as the x11 client implementation.

So the important consequence of this design is that you cannot extend the current interface to expose information from the client window without extending internal interfaces in KDecoration2 and KWin. That alone precludes building a plugin out of tree since it would need patches to two unstable interfaces in two KF5 libraries just to find out what to draw. It also means that if we have to extend these interfaces we *really* want to try to do it in a way that upstream will accept, such as exposing the remote name in addition to the caption.

It would have been great if this code instead treated the window properties as a map of property names to values. The interface would have been very simple, the properties would become iterable, and all native properties could be exposed automatically. I wonder if the developers would accept a patch adding a property map to the client with a view to moving the existing properties into it later - something to consider for the future.

Now to the actual plugins.

Theme plugins take theme files in some custom format like a tarball of images and scripts , and render this as the decoration. Optionally as in the case of the current plastik plugin there can be some C++ code to customise stuff like drawing buttons.  I am not going to spend much time on themes for the simple reasons that they don't really provide what we are looking for and they require more work. For a native plugin if we had the label and VM name available we could change the drawing code to use them and mostly be done. For a theme we would need to expose that information to the plugin scripts, change the theme(s) themselves if they override the colors and provide fall back code in the theme engine if not. Also of the three formerly popular theme engines only the one authored by Martin has been ported to KF5 AFAIK (its internal to KWin) - and it is now crash prone, often taking out KWin in the process. The suggested work around is to use breeze.

Oxygen has its window decoration code at https://lxr.kde.org/source/kde/workspace/oxygen/kdecoration/ and Breeze is at https://lxr.kde.org/source/kde/workspace/breeze/kdecoration/ for reference. Superficially both are fairly similar as far as window decoration handling goes.

For breeze, if we expose the VM label through the DecoratedClient interface then we could fetch it at https://lxr.kde.org/source/kde/workspace/breeze/kdecoration/breezedecoration.cpp line 105 (Decoration::titleBarColor) and this should be sufficient (untested). Oxygen presumably has an analogue but if we only support one style i think it should be the existing default. This approach would avoid changing the actual drawing code which I haven't begun to understand yet.

I need to investigate the existing palette mechanism further as in theory it is much more flexible and has the potential to work with multiple styles.

    >What a pity... Out of tree decoration plugin for KDE 4 worked well for a
    >long time. Does the same applies to themes (if answer to previous question is
    >positive)?

Should be answered above, themes would still require internal changes and would be more work as the theme engine itself would need to change. I am moving more and more towards using breeze as the best (default) option.

    >That's a good idea. In fact VM name is something like remote machine
    >name :)

Absolutely, given the machine name is already in use it is less cognitive shift to expose the VM in the same way i.e.:
- App running in dom0: "Window Title"
- App running in personal domain: "Window Title @[personal]"
- App remoted through personal domain: "Window Title @remote.host[personal]"

    >Does this means that "remote machine name" isn't exposed in that client
    >interface yet? Only already composed window title?

Yes, exactly:

    >Can you paste a link for the client interface doc/spec/header, for
    >reference?

See https://lxr.kde.org/source/kde/workspace/kdecoration/src/decoratedclient.h line 68. The caption() property is exposed but this value already includes the remote name. If we don't initially care about formatting the VM name (in bold for example) then we can just append the VM name to the caption in the concrete client implementation and not change the decoration interfaces at all. See https://lxr.kde.org/source/kde/workspace/kwin/client.cpp line 1437 (Client::setCaption) for where this change would be made. At line 1480 you can set e.g machine_suffix = QLatin1String("[personal]"); and rebuild to mock up what this looks like. The full code would add the qubes property names to atoms.cpp and use m_client.fetchProperty() here to get the VM name. I will prototype that shortly and add a link to the bug.

    >In the worst case (or maybe not such bad?), decoration
    >plugin/theme/whatever can extract VM color from VM settings based on its
    >name. So having: a) VM name, and b) ability to run some code on per-window
    >basis would be enough.

I think if we accept that the plugin code must live in tree then we don't want to be doing mappings using an external source of data via e.g. VM settings. There is no way that code would be accepted upstream and we would have to maintain it forever. If we must then so be it but I would hope not.

    >But if there is simpler option (like reusing existing control for
    >decoration colors), of course it would be simpler to reuse them.

Yes!

    >> There are of course other issues like forcing borders to be drawn
    >What do you mean by this? VM have very little control over window
    >properties, so advanced features like "border less dialog windows" or
    >such are out of VM control. Is there any situation where normal windows
    >get no border?

I mean here making sure that dom0 always draws the borders, e.g. that border width isn't set to 0, borders aren't disabled for title-less windows (if that's possible) etc. Nothing to do with VMs, its more making sure that the style defaults are correct from the sounds of things. Remember I've never looked at KDE code before and I'm new to Qubes too :-)

    >> the system tray and task bar,
    >If standard "System Tray Protocol"[1] is still supported, it should just work. At
    least in theory ;)

The system tray was completely b0rked by the devs in KF5 until they backed down and implemented a shim for backwards compatibility. See e.g. http://blog.davidedmundson.co.uk/blog/xembed_back. I would not assume anything without checking the code and/or investigating personally hence my comment.

    >https://github.com/QubesOS/qubes-issues/issues/1784

Great, thanks!

So, I think if we are prepared to have the look and feel change a little we could have this functionality (mostly) done fairly quickly. As an initial implementation I'm thinking:

1) Append the VM name to the machine name and display it as a suffix on the title without extra formatting.
2) Have the window proxy code set the palette file property from the qubes label (to one a set of files in /usr/share/qubes/color-schemes/ or similar).

This would give us the VM name in the title for all decoration styles and coloured borders for breeze plus any other styles that respect the palette setting.

Going forward we could push upstream for the machine name being exposed separately so we can display it differently (bold etc), and push for all default themes to respect the custom palette (Both of these stand a good chance of being accepted I think). We also have the option of changing the implementation later should the interfaces stabilise.

This seems like a good starting point for a very small amount of code.

Cheers
Jon

[Jeremias E.]

Hello,

was there any further progress regarding this issue?

Best regards
  J. Eppler

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Mar 23, 2016 at 02:45:18PM -0700, Jeremias E. wrote:
> Hello,
>
> was there any further progress regarding this issue?

Yes, see here:
https://github.com/QubesOS/qubes-issues/issues/1784

In short: mostly done, some details needs to be worked out. Generally
its waiting for me to merge the changes.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW8xF5AAoJENuP0xzK19csY+MH+wc/IrzZK+oTEvOf0iGy0Cwb
yXzxOqUnhYQBv7fusH40TYV8ybCQGgjWIzjY9nWuNusn75LxJjZOHaj1pQWmq9VC
ehK2LvCh/92Y8ukXmhjPZz/6L3iqgIBHzk1UhDdoKcx7vZnlNpVW13tEloETwB4a
gM8IKKzVU4ApL+JfBVEYyuH0N1ekqoD3LFwzGWWwNjIiX9/DzFKura57vHlq5s9U
njOI+kqg1FI+DqnuaKFD2wUJltL69MVk5aIr/7tGDFEFljqjIL8DtLt2v7eaWA1v
KDw2I/CZciswPTcv8p72NrMZOiO7IytzNm9Fb51Tv8nrOkBlnnKknp8QPJdO12c=
=7yKH
-----END PGP SIGNATURE-----

[Eva Star]

Related to this:

https://github.com/QubesOS/qubes-issues/issues/2042

Maybe better to add some solid dot to bottom right/left corner of the icon? 4px x 4px dot.

Instead of recolor full icon.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

NM applet icon already use red square (with "X" inside) in right bottom corner when there
is no network connection. And given the icon size (16x16) it may obscure
important parts. Anyway, there is some progress on coloring the icon,
see github.

- --
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?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQEcBAEBCAAGBQJXVfzLAAoJENuP0xzK19csqrkH/itx+A3KW2UMRyINnqbx9OaN
gXFTRtl46LjL5XcgShbLIr0sPadkFhXH5Kv5zjcRejsj7GEWI3v7NVCzLAg2C8i+
k+gt3pT3DWZItQyTqkLsa2jh5DC5qKtcGpZinmnUqL8H17Y/PDo388Hn9S3wOC7F
NsPJn3rz7033DNyG2pMPQjVHLh+Sl5k0stObkAM09v71+XVaurIVo3YinzoFmFjH
dn9HbfcIcZBoBhBULsEVhypk+MrANI81v41gIguqs5jhhFQCIxyNJkvIGypi+4Z7
JEeGXFh+LaNdRa8t1BiO9Hblb7dSzKaIMv68UJ6915w5bWb2PWVRF8u3Wx3OZ98=
=wBE4
-----END PGP SIGNATURE-----