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 #1806 (comment)

[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

[DemiMarie]

Right now I feel the central "problem" this issue was created to address, has been lost. Where would the value of Flatpak integration be, and to whom? What features, also?

Sorry, that was poorly phrased. What I meant is that if GNOME had already written code for Flatpak integration, we might be able to use some of it.

[demeralde]

I'd even argue using the Pop!_OS shell instead of regular GNOME. It's the best of both GNOME and i3. If someone implements this flawlessly with Qubes, I think I'd be sold.

[ninavizz]

Being able to integrate the DMenu stuff into Qubes w/o requiring the full tiling (primary) switchover to i3 would be a giant win for users, I suspect. LOTS of requests to bring D3 functionality into the new app menu stuff, so i3 users don't have to pick one or the other.

[v6ak]

Dmenu is cool (I use i3 BTW) and I love it, but I am not sure if it is what Gnome/Xfce/KDE users usually expect: 1. It doesn't show any icons. This fits well to i3, but can look quite strange in Gnome/Xfce/KDE. 2. It cannot be controlled by mouse or touch, just with keyboard. 3. When you open it and forget, it has some unwanted side effects. It seems to prevent screen lock and IIRC also prevents other windows from being used. User might not notice that they need to press Escape. Technically, using dmenu in Gnome/Xfce/KDE can be matter of just one keybinding, as it is in i3. It's really easy. But I am not convinced it is a wise default in non-geeky desktop environment.

[v6ak]

That said, it is completely OK to document how to use the i3-dmenu-desktop with other Desktop Environments.

…

[ninavizz]

On this topic, from the AppMenu survey:

"1) Make Qubes OS more usable for people with KDE-based templates, dolphin and Qt filesave/fileopen dialogs.
2) Each KDE-based qube should have shortcut in tray menu - open dolphin (or filenamanger script, the same as currently done with terminal).
3) Each qube should have an optional submenu with custom links, e.g. this qubes is for browser, this one dolphin (e,g. samba via vpn), this one qbittorrent and etc.
4) Make Qubes OS better for people with 30+ VMs. Storage space is cheap, so why not use plenty of them. But it causes troubles currently, start menu in XFCE opens 3 seconds for the first time. It has no search too (XFCE is not great and nor comfortable), so scrolling and searching VM manually is also a pain. So, I prefer not use start menu at all in XFCE, better to open dom0 terminal and run qvm-run vm konsole & from history. Yes, current XFCE menu is that bad if you have many VMs.

[ninavizz]

@v6ak Thank you for the excellent feedback points on the DMenu stuff! Users across DEs really want more keyboard-only control of their OS... so while, yes, it was only really i3 and super-Linux folks requesting DMenu outright, it is a realm of inquiry I like having open to explore some more (both with users, and technically).

[v6ak]

Hmm, when thinking about dmenu-like functionality rather than specifically about dmenu: Xfce has some similar functionality (Alt+F3, xfce4-appfinder), but it has two drawbacks. First, users might miss it. Second, it does not fit that good to Qubes OS. In Qubes OS, you might often have some apps used in 30+ VMs. In such case, I usually want to type part of the app name and part of the VM name (e.g., ”ban fire“ for ”banking: Firefox“), which doesn't work well with Xfce App finder. However, it can be easy to use some other app finder instead, as it is just an application bound to the keyboard shortcut. Advanced users can use i3-dmenu-desktop instead, as long as they don't mind the UI mismatch. But there are probably multiple such apps, one will hopefully fit well. Gnome has a built-in search which is IMHO pretty visible. I am not sure it it fits well to Qubes OS, but I am mildly convinced it is OK. Unlike Xfce, it would be probably considerably harder to replace the search. KDE – IIRC, it has some similar functionality, but my last attempt to use KDE is quite old and I don't remember it enough.

[SvenSemmler]

dmenu (i3), appfinder (xfce), spotlight (mac) ... ... it's all the same principle: hotkey, type a few letters, return Over time you build up muscle memory, especially with the 10-20 things you need all the time every day. Pretty soon you are launching apps faster then the time it would take to move your hand from the keyboard to the mouse. That's what's so powerful / addictive about this model. It's not good for discovery, but if you already know what you want nothing can beat it in terms of speed and minimal friction

[ninavizz]

Yup! All of this, we need to make work with Qubes. Not rocket science, just mental models and details to finesse. And, developer time to make fit well.

Also: Having now finished the first pass of synthesis on the appmenu survey (it'll take about 3 passes until I'm "done" with a publishable article), I can assert a strong interest in Gnome from just the open form comments on that. There were also some open form comments about KDE (and many complaining about its perceived bloat on system resources, heh), but all of that will be quantified in the article that ends up getting published. Just FYI.

[unman]

[quote]

KDE ??? IIRC, it has some similar functionality, but my last attempt to use KDE is quite old and I don't remember it enough.

[/quote] Yes, KDE has built in search both in the menu and as separate drop down.

[DemiMarie]

There is a major problem with GNOME’s Wayland compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/1836. In short, GNOME does not support server-side decorations on Wayland, at all. It expects each client to draw their own. That means we need to either draw these decorations ourselves in the GUI daemon, or convince Mutter’s developers to change their mind.

[DemiMarie]

Update: Mutter will never support server-side decorations, which means that the GUI daemon will need to draw its own decorations itself. GTK is the only way to draw decorations that are consistent with the rest of the desktop environment, but GTK is not well-suited for this task, as it is not friendly to direct interaction with Wayland.

@ninavizz: how important is it that the window decorations be consistent with those provided by GNOME? Ensuring this will likely add substantial complexity and may cause problems with accessibility support.

[ninavizz]

Responded to @DemiMarie in an outside chat. TL;DR, "GNOME-y" or "KDE-y" etc are less important, than supporting colored frames in Qubes as elegantly, usably, and otherwise neutrally as possible. #6414 shows a proposal that does not have to be married to XFCE, but in an ideal universe is how I'd like windows to look in Qubes. :)

My preference for GNOME overall, is for how its family of components all work across UI functions. Can elaborate later, if desired.

[DemiMarie]

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1014 is going to be another difficulty. The recommended workaround appears to be a shell extension in JavaScript, but that is only an option for icons in the GUI qube.

[DemiMarie]

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.

From a purely technical perspective, client-side decorations are probably the best option. They are fail-secure, as errors will crash the GUI daemon. They are also portable to all Wayland compositors and X window managers, and have the same look and feel on all of these platforms. In light of #6414, this is actually desirable! Desktop environment theming code is very complex and I would prefer to not rely on it for security, whereas client-side decorations should Just Work.

That said, good client-side decorations are a LOT of work, especially since accessibility is a requirement. Having the GUI daemon draw them would add a significant amount of complexity. That is undesirable in one of the most security-critical parts of the system.

[DemiMarie]

I finally figured out a solution last night:

Instead of launching the GUI daemon normally, the GUI daemon is launched by a GNOME shell extension. The extension uses the MetaWaylandClient API to allow it to identify the windows owned by the daemon. This is race-free by design, and is designed to be secure against spoofing by untrusted sandboxed (ex: Flatpak) clients, so it is more than sufficient for our purposes.

Before the daemon draws a window, it asks the extension to draw the window’s border. The daemon only draws the window if the extension draws the border successfully. Otherwise, the daemon considers this to be an error condition, preventing a window from being drawn without a suitable border. If the extension is not loaded, the GUI daemon will never be launched, which is again a safe failure mode.

[jonkri]

It's great to see that the Bountysource bounty has reached $6,400. Hopefully we can see some more progress towards this soon!

Merry Christmas, all! 🎄

[code3z]

Hi, I already got this working a little while ago: https://gist.github.com/code3z/244ea17d306f11fdf1127c8d4ce5296c
There are a few bugs, like with the microphone and HDMI, but I think those have to do with the OS and my hardware, not GNOME. I have been using GNOME with a second display for a few months now. I posted the code and instructions for window decorations but it is a bit hacky.

[marmarek]

After several considerations, sadly it seems like official support for GNOME is not a viable in Qubes OS. There are several technical details (you can find them in the discussion above), but the summary is that GNOME is tightly integrated with their vision of the desktop which is incompatible with Qubes OS. Some of it can be tweaked with extensions (but the API there changes so maintaining it will be substantial amount of work), some requires patching at source code level (which is even more work to maintain). And some (like server-side decorations) won't work under Wayland at all (and the native X11 support is going away).

If GNOME approach will change, we may reconsider this decision. Until then, there won't be official support for GNOME. If somebody is willing to maintain set of packages and extensions that make GNOME functional on Qubes OS, we have a contrib repository that could be used for that.