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?

[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!

[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]

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).

[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.

[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?

[ghost]

What's the reason @bnvk stopped?

[marmarek]

Turned out to be harder than "just create custom theme", see #1806 (comment)

[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

[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).

[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

[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

[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?

[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

[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.

[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 #2281 (comment) for more details.)

[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 #2281 (comment) for more details.)