GNOME extension: Qubes Window Borders

General Discussion
1

I’ve created a GNOME extension for Qubes OS that adds colored borders to windows. I hope this is useful for you.

7 Likes
2

Wow, awesome. Wasn’t this some kind of permanent blocker for getting GNOME into dom0?

So what’s the catch?

Tagging some related people from a previous thread: @ninavizz @Demi

Here’s a picture from OP’s GitHub repository for more attention:

screenshot
screenshot1920×1080 217 KB

2 Likes
3

would be awesome, when secure.

right now i am using baremetal fedora on a different machine and really enjoy mouse gestures :>

thanks for the work apebl :slight_smile:

1 Like
4

This is indeed super cool, thanks! There are three other problems with GNOME that might or might not be dealbreakers:

  1. GNOME Shell’s integration with evolution-data-server would be limited to local calendars only, as there is no network access in dom0 or a correctly configured GUIVM.
  2. GNOME Shell doesn’t support tray icons. Fortunately, this is now handled by an extension that is maintained upstream. It only supports XEmbed, but thankfully XEmbed is what Qubes OS uses.
  3. GNOME Shell doesn’t have a stable extension API. This means that this extension would need to be maintained for as long as GNOME is supported. In particular, this would need to be ported to a new version of GNOME Shell before that version can be used. This might cause problems in GUIVMs, which don’t use a frozen version of GNOME Shell.

I think the first two problems are not worth blocking GNOME forever, as the first is just a not-working feature and the second has a workaround. However, the third would be an ongoing maintenance burden, and I believe none of the core team uses GNOME or are familiar with writing shell extensions. Personally, I think this might make sense as a contrib package with the appropriate dependencies to ensure that it is always installed alongside a compatible version of GNOME. I’m not sure if it is something that makes sense as an official package.

Additionally, where should the blue Q launcher go? In a Wayland session, it currently uses wlr-layer-shell to position itself. A GNOME Shell extension could launch it using MetaWaylandClient or it could be made to fall back to X11.

@marmarek what are your thoughts? I know that using GNOME has been rejected in the past, but that was before this extension was available and before GNOME got XEmbed support.

2 Likes
5

This looks really cool indeed. For the borders, I have slight concern if this will be visible enough, especially when windows overlaps, but it might be okay too.
And what if an application puts its own controls in the top left corner (Evince for example puts side panel + page number entry there).

As for GNOME in general, there are few more concerns:

  • the API stability might be problematic for GUI domain, but I guess users would need to wait with switching to newer Debian/Fedora version until somebody updates the extension. And Arch-based (or other rolling distro) GUI domain would be unmaintainable at all.
  • menu integration, to replace the standard GNOME menu
  • usually we disable several features which don’t make sense in dom0/GUI domain - at the very least network-related features and links to file manager browsing dom0 filesystem, and proposing to mount various partitions in dom0; I’m not sure how much of that is in GNOME, but AFAIR it has integrated NetworkManager support, which doesn’t really make sense in dom0.
  • and finally, heavy usage of GTK4 is not very friendly to virtualized environments; while dom0 has access to GPU and can use accelerated rendering there, it may not be the case in GUI domain, so it will be less and less usable there…