Add support for GNOME in dom0/GUI domain

[marmarek]

Tasks here:

• [ ] window decoration (colorful frames)
• [ ] stripping unneeded components (file manager, automounting devices etc)
• [ ] adjusting application menu
• [ ] Qubes Manager integration (whatever it means)

[tasket]

Has there been any open discussion of the need/desire for this?

[bnvk]

@ttasket yes, there has been some discussion on the mailing lists, but ultimately it was a decision of core team to work towards this!

[woju]

Results of a preliminary research:

• GTK+3 prefers client-side decorations (CSD), though it still draws decorations around windows which don't draw them the GTK+ way; the code used is the same, CSS based, but done by the window manager (Mutter)
• one general problem with GTK is that some applications want to customise their headerbars (they add some buttons); the result is two sets of decorations; we probably can design our decorations to just include thin border (like in "Activities" gnome-shell panel) and a label with domain name
• based on comment by someone on one of the gnome-related IRC channels, it's currently not possible to do it in Mutter without patching
• we control both the client and server side (the window belongs to gui-daemon and we can supply an extension to gnome shell)
• @marmarek doesn't want to convert gui-daemon into GTK+ application, because:
  • there are some problems foreseen (something around event ordering, which I didn't understand
  • he would have to do it
• playing around gnome shell JS console proved unsuccesful (the guy on IRC was probably right)
• the following code is an example of styling window decoration; instantiation of Gtk.HeaderBar seems to be mandatory, if not created, the decorations are drawn by Mutter at least in 3.10 (Debian 8)
• messing around style providers to write custom implementation in Python (to generate dynamic colours, because labels may be changed) was also fruitless, because they use private interfaces and the public, documented interfaces don't really work

#!/usr/bin/env python3

import pdb
import gi
from gi.repository import Gdk, Gtk

def get_css():
    return ''.join(
        '''
        .qubes-label-{name} .header-bar,
        .qubes-label-{name} .titlebar,
        .qubes-label-{name}
        {{
            background: dark{name};
        }}
        '''.format(name=name)
        for name in ('red', 'green', 'blue')).encode('ascii')

def main():
    provider = Gtk.CssProvider()
    provider.load_from_data(get_css())
#   provider.load_from_file(FILENAME)

    Gtk.StyleContext.add_provider_for_screen(
        Gdk.Screen.get_default(),
        provider,
        Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION
    )

    win = Gtk.Window(title='titlebar')
    win.get_style_context().add_class('qubes-label-blue')

    header_bar = Gtk.HeaderBar()
    header_bar.set_title('header-bar')
    header_bar.set_subtitle('dom0')
    header_bar.set_show_close_button(True)
    win.set_titlebar(header_bar)

    button = Gtk.Button(label='Break to PDB')
    def on_clicked(widget, win=win): #, header_bar=header_bar):
        try:
            pdb.set_trace()
        except bdb.BdbQuit:
            Gtk.main_quit(widget)
    button.connect('clicked', on_clicked)
    win.add(button)

    win.connect('delete-event', Gtk.main_quit)
    win.show_all()
    Gtk.main()

if __name__ == '__main__':
    main()

# vim: ts=4 sts=4 sw=4 et

[woju]

Oh, and forgot to add: there are two programs which aid debugging GTK+ applications: GTK+ Inspector (>= gtk 3.14) and gtkparasite (for older, like 3.10 in jessie).

[mfc]

from my understanding of the warsaw meetings, @bnvk is no longer attempting to implement this anymore, so I removing it from being assigned to him. I am assigning a help wanted label as well.

[ghost]

What's the reason @bnvk stopped?

[marmarek]

Turned out to be harder than "just create custom theme", see https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-202955011

[adrelanos]

This might not happen for Qubes R4. Source: Qubes lead engineer @marmarek: https://groups.google.com/d/msg/qubes-devel/cberCRs_nFE/reNS1BKOBwAJ

[liilac]

I will try find them later, but there are a set of patches to metacity to enable window labelling and colouring for the MLS policy under SELinux. I imagine that may be helpful as reference (SELinux window labels are stored the same way as Qubes ones).

[marmarek]

Very interesting, can you paste a link? @ileyd

[liilac]

@marmarek Sure

I believe there are two different sets of patches available publicly. Also, I think there are some for Openbox and XFCE as well.

Mind you these are OLD, from when there seemed to be a burst in interest in producing a functional MLS desktop with SELinux/X11, but I'm sure newer versions exist.

It might be worth emailing the authors to that effect (there are definitely still people working on MLS with SELinux).

Bugzilla page Screenshot of demo

Different patch (mailing list thread)

---

Some related links Presentation relating to the above Notes on a previous SELinux summit, covering some similar things as above SELinux wiki page on MLS

[Drubble]

It'd be a shame if Qubes gave up on Gnome altogether. I really find it a much nicer DE than Xfce/KDE. Is it still on the roadmap?

[andrewdavidwong]

@Drubble: AFAIK, we're still looking for a GNOME dev: https://www.qubes-os.org/join/#gnome-desktop-environment-developer

[rootkovska]

I would just like to note that this is currently a very low priority for us to migrate from Xfce to Gnome. At least for Qubes 4.0 and 4.1.

At this stage (4.0/4.1), even if we got somebody to offer patches, the core team would likely not have time to review the patches. A significantly more important task, related to GUI re-engineering is #833. Even thought it might seem that these should be fairly independent, in practice I highly doubt it. We will need some kind of a fallback mode for when GPU passthrough cannot be used on a given hardware in which case to use "software" GPU domain, as explained in #833. This, however, would most likely mean that GNOME would work horribly in such a mode (no GPU access), and so we would need to keep Xfce4. But maintaining two different environments would be a very resource-consuming and error-generating situation.

I suggest we reconsider this after we get #833 implemented. So, 4.2-ish.

[v6ak]

Optional task: verify that touches work well with multi-monitor setup when using input proxy – regardless of screen positions and primary/secondary screen status. (It might require no implementation, but it should be verified if it works well. See https://github.com/QubesOS/qubes-issues/issues/2281#issuecomment-386517462 for more details.)

[telepath]

I've posted a Bounty on this, in the hopes it raises someones interest in working on this.

[jonkri]

@telepath: Great idea! I just added $150 as well. :)

[jonkri]

For those of you not following this issue on Bountysource - the bounty is now $400. 🙂

[liilac]

I remain interested in working on this, however I expect it'd be a bit more work than $400 worth 😉

[liilac]

Also, I would urge you to try and engage those who work on trusted computing with Linux, particularly those who work on MLS/MCS support with SELinux. This is duplicating a lot of stuff they've long worked on.

[v6ak]

I've just added $100, so it is $500 now.

[jkhgvfgvsth]

I remain interested in working on this, however I expect it'd be a bit more work than $400 worth wink

The thought process behind programs like BountySource is that users can over time crowdfund to add more funding. Programs like FOSS Factory work similarly.

Even smaller bounties can also help show that people want a feature, kinda like a "put your money where your mouth is" moment. Basically saying, we want this and are willing to help fund it.

Bounty Status Widget:

Source Code for Widget

[mr-sour]

For fun I started an experiment to see if I could hack some borders onto some clients. I was able to get that far and as much as I could tell client themselves could not mess with this border I used the .ssd css tag which mutter uses to render server side decorations. As you can see in the photo below I have some wonderful little borders. I'm not gonna claim to be a expert for all I know this is like super bad and isn't working the way I think it works. That being said I think I'm going to continue messing around with this and see if I can't create an extension that adds window decoration as far as I was able to see this tag and this support was added in late 2016 2017 which to my knowledge was after the initial investigation of this. Or I'll go in a complete circle but hopefully I'll at least be able to articulate why this wont work either.

This was done on fedora 30 (Ignore the background) with the latest version of gnome + some patches. It also wasn't perfect it looks like when you specify .ssd animations dont work for the border and I noticed some strange artifacts (probably because the animations aren't working).

/* focused window (server-side ) */
.ssd .titlebar {
    border: 2px solid #008000;
    border-bottom: none;

}

/* unfocused window (server-side) */
.ssd .titlebar:backdrop {
    border-color: #006400;
}

[marmarek]

Does it work for titlebar too (for windows that don't draw it themselves)? I'd recommend testing with xterm, as an example application without client-side decoration. Where exactly you put that css? How to get it different on per-window basis?

But generally, it looks like a good direction!

[mr-sour]

@marmarek for experimenting I did 3 things. I set this CSS in ~/.config/gtk-3.0/gtk.css which will globally draw a border around all windows. I also used GTK inspector and the JS gnome command shell to set it on windows that are already open thats whats pictured above . The 3rd is I edited the desktop files to launch with separate GTK_THEME variable.

The GTK_THEME I think is a dead end because I'm fairly certain the application has to respect that setting and it also will remove any user themes. But playing around in the JS shell proved to be fruitful so I'm going to keep exploring and see if I can't stumble my way though making a plugin that attaches these borders without messing with mutter or having to rebuild gnome-shell itself.

I also just tested prompts like settings or open file and they get the same border as the parent (using the inspector again) so hopefully thats a good sign and this is a good avenue to add decorations. Just tested xterm and it worked just as pictured above but without my beautiful dark theme being applied. Let me know if there any specific thing you want me to look at/try, but I'm going to try to figure out how to go from the inspector applying this to a plugin. This is also in a wayland session I checked some Xwayland clients and they also get borders but I have not checked to make sure its all working the same in a X11 session.

[marmarek]

This is also in a wayland session I checked some Xwayland clients and they also get borders but I have not checked to make sure its all working the same in a X11 session.

gui-daemon currently is an X11 application. It would be useful to check under X11 session too. I wonder how gui-daemon would work under Xwayland. Tricky part is shared memory - currently we LD_PRELOAD wrapper around shm* calls to intercept local shared memory calls and do inter-VM shared memory instead. This could break under Xwayland, but there is a slight chance it would work. Long term, we'd need to rewrite gui-daemon to wayland anyway.

As for GTK_THEME, yes, that's probably dead end. It would be useful to check how JS shell exactly set those colors - maybe gui-daemon could simply do exactly this itself? Not sure about wayland, but on X11, the canonical way for this is window property. I recommend playing with xprop tool. Once figured out what properties are needed, gui-daemon has option to set arbitrary properties.

[mr-sour]

For a XORG session I had to tweak the CSS and do some other tweaks to achieve what I did on the wayland session. Mainly I had to change .titlebar to decoration and applications with CSD didn't seem to care about this (strange it worked in wayland) But I was able to find a way to disable CSD with the aptly named gtk3-nocsd package where I was able to mirror the above photo but on a XORG session. EDIT: One thing that does work better on the Xorg session is on wayland when you maximize the border gets hidden (or drawn off screen) in xorg the border is still viable when you maximize windows.

[maximilize]

Actually is there anyone who wants to work to get the bounty? I don't know how much work this issue is, I guess it's quite a little. I would be willing to add some to the bounty, if ever this makes real sense and this issue will be finished within the next future.

[deekosta]

I don't have the knowhow to help with this, but I can say I have great interest in seeing this become a reality. GNOME is by far my favorite DE to work in. Simple, focused, intuitive.

[mr-sour]

An update on some of my above findings. While some applications when forced to use ssd decorators draw double borders (which in my opinion is fine) Others do not. The other applications are most the ones that come packages with gnome and decorate the title bar. A good example of this is calculator which has a mode switcher in the bar causes all SSD decorators to droped by mutter. As far as I can tell this is intentional but fairly annoying. What I was attempting was a fancy theme that utilized css selectors to create these ssd borders but that not gonna work without patches to mutter. As a side note allot of the stuff I did in 3.32 is not very stable in 3.34 I am running into my windows getting replaced with black boxs so Im trying to nail that bug down.

not that I know all of the work that needs to be done @maximilize but I would say the task of drawing secure borders which are typically done with server side decorators in gnome which wants to only use client side decoration and has no intentional up streaming any server-side decoration support is non-trivial. I'm still fairly certain that an extension for gnome-shell will have to be made but I'm exploring all the avenues that would hopefully allow gui-daemon to hook in with minimal fuss. But right now that isn't looking to good I have no intention of doing all the work to bring gnome to qubes but to just help with some pieces of the puzzle.

[marmarek]

Not sure if that is helpful, but there is an alternative solution: use client-side decorations. The actual VM windows are technically owned by gui-daemon process in dom0 (or other GUI VM in the future), so we have full control what is does. The issue here is it being plain C application, accessing X11 messages directly - which may be highly non-trivial to combine with GTK3 code for drawing decorations. But maybe I'm wrong here? Note this part of qubes is very fragile, as there are a lot of different applications, each with own set of quirks - causing issues like like #5424 or #3982.

[mr-sour]

Thanks @marmarek I'll look into it. I guess I get to pick my battles, but CSD decorations would fix the issues for apps that have a customized title bar which in its current incarnation mutter will never draw SSD decorators for.

[marmarek]

Note the applications running inside VM have no way to talking to mutter directly, mutter has no idea if application inside draws its own decoration or not. Not even if that's GTK application or not. From mutter perspective it's always gui-daemon (qubes-guid) non-GTK application.

[mr-sour]

So with recently having some time on my hands due to quarantine I've picked this up again. I've begun hacking together a gnome extension that will run in dom0 and will provide the capability eventually to get the correct border color and then use Cogl/Mutter to draw said border. Heres the super alpha screen shot of what I was able to hack together in a night. there's a semi long path till this is usable but I figured I would post it here in case my life gets busy and someone else wants to pick this up. I think my prior attempts with gtk while they looked really nice there were a bunch of unknowns and was probably going to end up being to complex in practice.

All I did was find a extension that iterates over all the window actors and then made it draw a red border. over the week I'll try to clean it up and write the interfaces to set the color. Once I have that all working I'll circle back here and see if we can't come up with a strategy for getting window color. here the photo of what I got so far.

repo for the extension https://github.com/mr-sour/gnome-colored-borders

[mr-sour]

Quick update after doing a little more math then I would have liked. The borders no longer draw way larger the the window. The picture above was a border drawn around the window actor which as you can see is quite a bit larger the the window frame itself. I still need to draw the border in the window actor but have since updated it to adjust to the window frame edge. I'm gonna start poking around in gui-daemon as the next part of the extension development is setting per window colors. One of the things I noticed while inspecting though GJS objects was a MUTTER_HINTS property on each window. I'm planing on seeing if I can patch gui_daemon to store a window colour value in that hint. Once I have the hint in there I can patch the extension to then set the colour based on that value. Or I'll learn that it was a terrible idea and come up with something else. From a the extensions point of view the MUTTER_HINTS solution is ideal as it would work regardless of x11 or wayland which as of right now the plugin has no x11 specific components and uses only mutter + GJS to render the borders so I'm hoping to avoid tying it to compositor specific features. development upto this point has happened in fedora 32 so I think I'll have to get a 4.1 testing release up and running to continue.

[marmarek]

Note the gui-daemon already has support for setting arbitrary property on its windows. See man qubes-guid, for example:

qubes-guid --prop=MUTTER_HINTS=s:some-string-value

What about other parts of the window decoration? Especially putting VM name somewhere, but also preferably coloring the whole title bar. The thin border is a good start, but for normal application windows it's easier to distinguish them if the whole title bar has appropriate color. This is also related to the CSD/SSD topic that was discussed here already.

[mr-sour]

well isn't that convenient! I'll look into colouring the top bar I believe the meta_window object which I'm already looking at with mutter will allow me to force a colour on that bar. early on I was playing with other effects on the windows such as tinting the entire window (not with a overlay but by adjusting the hue of everything being rendered) so I think I just need drill down into that object and Ill be able to set that. I even saw some GTK related stuff in that object but from what I've researched/experimented with I think it would take somone who really knows the internals of mutter/gtk to effectively be able to modify those objects in a reliable fashion and would probably be just as complex as trying to codify what I was doing previously with the GTK inspector

The reason you dont see the VM name is I developed this on a plain install of fedora 32 workstation not on not qubes. When I installed @gnome-desktop package in qubes the VM name was already apart of the window but the aforementioned meta_window object will allow me to change that to if I'm crazy and was just seeing things. (or if it doesn't work in dom0 fedora 32 I looked at that in dom0 fedora 25). My goal is to just get a decent POC for the window decoration working and then we can evaluate my solution and decide if its worth refining.

[marmarek]

Yes, developing it in plain non-qubes gnome is definitely fine. But I'd recommend testing also on some non-gtk and non-qt application. Perhaps xeyes or xterm. This will be closer to how qubes-guid currently behaves.

[mr-sour]

The borders render regardless of qt mutter other... I have yet to find something that's not getting caught so thats a good sign. As for the colored title bar allot of windows in gnome don't even have a title bar. If I force a title bar on those windows it looks funny cause it double renders stuff like the close button. On gnome native apps specifically there's allot of issues as you can put buttons and other stuff in the top bar which really blurs the line of what is a title bar. I'm gonna play around with it but it doesn't look like there's a silver bullet that covers everything so I think there will need to multiple soulutions to handle various cases.

[strugee]

If I force a title bar on those windows it looks funny cause it double renders stuff like the close button.

This is already the case on XFCE though, if you run GNOME apps inside AppVMs. I don't think it really matters that much. I personally am not really bothered by it anymore - I just think of the application title bar as a toolbar that happens to have an X button that doesn't work.

[mr-sour]

@strugee Unfortunately the double title-bars render very oddly. https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-675217416 In my original screen shot you can see the borders are getting drawn with padding it looks like when you force decorations on a window that doesn't have them mutter draws them around that window object instead of the meta_win object that stops at the edge of the window frame. I was able to fix this by computing the size difference and coordinate difference and adjusting the bars I'm rendering. While I'm totally on-board with customized title bar I think this issue would require a patch to mutter I can try to fix it after the fact in the extension but that might have its own difficulties. It goes back to the CSD/SSD issue and gnome pushing for CSD in there own stuff makes this tricky to implement. I think the best option that wouldn't be super hacky/inconsistent is to just draw a title bar in the same way I'm drawing the border on every window regardless. Or we can decide that there might be a feature discrepancy until someone wants to take up implementing this at the mutter level. People have opened such patches/issues in mutter about SSD support but they all get closed due to varying reasons and gnome not wanting to support it.

[marmarek]

An idea: is it possible to tell gnome applications to not draw their client-side decorations at all? This could be some theme or other setting like this. If so, we could configure AppVMs with that and get rid of the inner decoration, instead of the outer one. I suspect the answer is negative, but worth checking anyway.

[v6ak]

Yes, we can: https://github.com/PCMan/gtk3-nocsd

There is even a Debian package in the official repository: gtk3-nocsd

For Fedora, you probably need to compile it yourself.

[mr-sour]

GTK has a setting but it doesn't work on the windows in question.

GTK_CSD.  The default value of this environment variable is 1. If changed to 0, this disables the
default use of client-side decorations on GTK+ windows, thus making the window manager 
responsible for drawing the decorations of windows that do not have a custom titlebar widget. 
**CSD is always used for windows with a custom titlebar widget set, as the WM should not draw
another titlebar or other decorations around the custom one.** 

https://github.com/PCMan/gtk3-nocsd I also looked at this which in theory gets rid of all CSD but its very inconsistent and doesn't work on every window. for example it does render a double title bar on gnome-terminal without looking funny but settings, tweak tool, lollypop , and calculator dont get picked up correctly and just dont get anything. If it was gonna work I think I would be able to also just customize the border with GTK but I think there's to many cases where it doesn't work to try and ship gtk3-nocsd and expect a good user experience. I think allot of this stuff this package does is what I already looked into last year and wont be a reliable solution long term. Also gtk3-nocsd doesn't work in wayland at all, where as everything I've done so far works with X or wayland.

I also tried abusing theme variants by setting _GTK_THEME_VARIANT and I'm sure it wont be very surprising to hear that CSD decorated apps dont care about variant settings. You can globally theme them no issue and I can configure the variant theme to customize the title bar but it only effects the SSD title bars all the CSD apps that dont have them dont care.

I'm just going to continue forward with just the borders (maybe make them thicker or make a setting to change the width) and just get things in a alpha state. Maybe as a later improvement we can look at decorating non CSD apps and then if a application uses CSD we can fallback to my current solution. I just want to get something that works everywhere first as I feel like its better todo something consistently thats at least supported then to put in all the work for the forced SSD decorations only to have it be inconsistent/buggy. We would just be setting ourselfs up for failure I bet as I'm sure it would be a moving target to try and support that.

heres an example of me running gtk3-nocsd the terminal decorations are working but the other apps aren't getting anything. The thing I did above that renders them incorrectly at least works everywhere. I can try opening a issue with mutter to see if they wanna fix it but I have hunch that its working correctly from there perspective as if a window doesn't have CSD it renders a title bar for it correctly and if it does use CSD it renders that all correctly. but forcing SSD onto a CSD window is something they've said they wont support on numerous occasions.

I hate to be the bringer of bad news but its how gnome has set things up and I'm just trying to work within that as best I can. I'm certainly open to ideas but It doesn't look like there's gonna be a silver bullet that allows gnome to be feature parity right off the bat.

[v6ak]

Aha, hmm. The gtk3-nocsd works perfectly fine for me, but I use it on Debian stable, which has somewhat older Gnome apps.

In my opinion, the problem is not in mutter, the problem is in apps that insist on CSD.

[mr-sour]

If you go over to the gnome issue trackers you can see plenty of discourse on the CSD transition and its certainly a hot topic when it get brought up. In this instance though it is a mutter bug. To force mutter/gtk to draw decorations you can run this command xprop -f _MOTIF_WM_HINTS 32c -set _MOTIF_WM_HINTS "0x2, 0x0, 0x1, 0x0, 0x0" But as you can see https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-677972686 the decorations render incorrectly its not the applications fault its just how mutter thinks they need to get rendered. to fix it means someone is going to have to patch mutter I think anything else would just be hacking around the root of the problem. As a compromise since I'm not sure I can patch mutter is to just try and get a reliable minimal viable solution with whats currently available with GJS/mutter apis and see what people think about it. If people think that a colorful border isn't enough and we really want it themed in order for gnome to be a viable desktop enviroment for qubes thats fine but I think its important to just start with something even if its limited and get the ball rolling.

From where I'm sitting even though while it would certainly be ideal to try and keep it as feature parity across the various desktop environments (i3,xfce,kde,gnome) the issues I'm facing might boil down to a statement like "Qubes integration on gnome only includes window borders because of issues x y and z within gnome until those issues are fixed/unblocked the integration will be remain limited in order to keep a consistent experience within gnome". I certainly glad people are talking about this though hopefully we can get some actionable items out of all this discussion. Hopefully this can evolve into something that is both feature parity but also not built on hacks that gnome doesn't support to some extent so this integration doesn't break with every release.

[v6ak]

Aha, not sure then. The large space might have been caused by Mutter, as well as by an application wanting to draw some semitransparent borders...

[mr-sour]

I've cobbled a spare computer together to start working on the qubes integration and interestingly the odd rendering bug I was seeing after forcing decoration doesn't happen in qubes. Even more interestingly It doesn't double render the title-bar but instead just moves the controls that were in the title bar down to there own menu bar. Seems worth investigating so I'll start messing around with that. The VM/Qube name no longer shows up in the title bar though so I'll have to see if thats something that I should try to apply in the extension or maybe patch the thing that normally sets the name. Also while its been awhile since I looked into this but a year or two when I was going down the GTK route I could have swore that 0 decorations were working. But I'm getting the coloured borders when I click on menu prompts in gnome so it looks like parts of it are working. I'm not attached to anything I've done so far so I'm gonna start experimenting with gtk stuff again now that its the newest version of gnome. I think I can make a css classes for each colour and try to activate them on a per window basis which would be super slick if it works.

[h01ger]

On Mon, Aug 24, 2020 at 04:54:57PM -0700, Christopher Sauer wrote:

I've cobbled a spare computer together to start working on the qubes integration [...]

just a 👍 from the sidelines watching!

Personally I won't use Gnome (because I love i3) but I'm still watching your efforts with joy, because I think it's important that Qubes runs nicely with the default UI of most major linux distros.

So, please keep up the great work & have lots of fun! :)

-- cheers, Holger

---

           holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.

[marmarek]

The VM/Qube name no longer shows up in the title bar though

There is a qubes-guid option for that: --title-name. Currently it's enabled for KDE only (https://github.com/QubesOS/qubes-core-admin-client/blob/master/qubesadmin/tools/qvm_start_daemon.py#L395)