Is gnome on dom0 possible?

It’s been a while since I looked at this, but last I remembered, the situation was something like this:

  • GNOME Shell is extremely extensible. However, doing so requires writing a GNOME Shell extension in JavaScript, and there is no stable API for these extensions. Failure of the extension to perform its job could cause windows to not be colored properly, which would require a security bulletin to be issued. While the Qubes team could test the extension’s behavior with the fixed version of GNOME Shell in dom0, doing so with the non-fixed versions in GUI qubes would be a significant maintenance burden. It would also require that the extension have a pinned dependency on an exact version of GNOME Shell, which could interfere with system updates.
  • GNOME Shell integrates with a massive number of services, such as GNOME Online Accounts, GNOME Weather, and NetworkManager. These services are useless in the GUI qube, because the GUI qube has no network access. On the other hand, GNOME Shell does not have support for third-party tray icons. The GNOME Shell developers recommend using other user interface elements, such as notifications, instead. However, GNOME Shell itself uses something analogous to a tray icon for NetworkManager, though it does not provide such support to third-parties. Since Qubes OS does not use NetworkManager in the GUI qube this is not helpful for us, and Qubes OS would need to either use a shell extension (which has maintainability problems) or just drop support outright.

In short, GNOME Shell makes a sharp distinction between stuff that is part of the system (GNOME Shell itself, NetworkManager, some other services) and third-party applications. However, Qubes OS necessarily replaces many of these system components, which leads to a conflict for which I am not aware of a good resolution.

3 Likes

To summarize the situation: GNOME has its ideas about how the desktop should look, Qubes OS has its ideas about how the desktop should look, and it would be a lot of work to make them play nice with each other. KDE and XFCE are much less opinionated, so making them fit Qubes OS’s needs is much simpler.

4 Likes

GNOME in dom0 is absolutely possible with

sudo qubes-dom0-update gnome-shell

but it is very janky compared to other distros like debian or ubuntu. as mentioned by other people in the thread there are also a bunch of issues with stuff like NetworkManager and similar stuff not integrating properly with the GUI

found it through

I havent personally looked at the author’s code for the color coding but they mentioned it is very hacky

Even with all the jankiness I still think it’s an improvement in many regards over the other DEs available but definitely would be nice seeing an official solution for some of the GUI elements as mentioned in

I understand why it isn’t being done due to limited dev time and funding but I’d persoanlly much rather see funding go towards the gui aspects with NetworkManager, a dock and desktop over color coding. Trimming all the useless stuff mentioned like weather services etc. would also be useful

Someone else will have to enlighten me on the argument for the prioritization of color coding because I’m simply not aware of their line of thinking.

I’d be curious to know in general how many people even actively use the color coding

Ultimately then, maybe there needs to be thought about forking or otherwise investing effort in a Qubes DE (Qubert? if it wasn’t still trademarked/copyrighted, Qesque? New DEs still occur, it’s not a closed field - just have to talk to the right people) rather than reliance upon desktops that do not expect to be running on top of Qubes (I mean, hell, even apps might benefit from a bit of forking too - to be better aligned with Qubes instead of shoe-horned in, maybe several products commonly requested those that are particularly thorny to make play nice regardless of what template you base your Qubes on?)? Frankly, the Qubes environment & goals may necessitate such a move as it may save on the bending over backwards required for adapting the existing DEs to it.

If it weren’t for the fact that a DE is a lot to ask of any group let alone a smallish group such as the current Qubes core devs - hoping always that it could grow much much larger. If we at least begin the talk, perhaps once a large enough base of people come along for this Qubes ride then these possibilities can become realities.

The only realistic way forward I know of is to switch the GUI daemon to use client-side decorations. This means that the GUI daemon (not the qube it serves!) would be responsible for drawing window decorations, instead of relying on the window manager or Wayland compositor. This will allow Qubes to work (at least to some extent) with any desktop environment, not just ones that have been made (either via patches or configuration) to support Qubes OS.

The difficulty with this approach is that it is a significant amount of work, especially since we cannot regress accessibility for disabled users. Accessibility is already a serious problem for Qubes OS, and making it worse is not something I consider acceptible. Generally, GTK has the best accessibility support, but the GTK developers are not interested in adding the hooks that Qubes OS requires. The only way to make the GUI daemon a GTK application, without needing patches to GTK, would be to use OpenGL for rendering. This would likely harm performance and is not something at least I am interested in doing. libdecoration will have a GTK plugin, but it is not accessible, and making it accessible would require patches to libdecoration, GTK, or both.

A completely new desktop environment would be significantly more work. If one could be made, that would be awesome, but I have serious doubts as to its practicality. This should not be seen as discouraging, but there is a huge amount of stuff that the Qubes team needs to do, so this would need to be a community effort for the forseeable future.

To summarize this post: I don’t see Qubes OS ever being able to use GNOME Shell directly unless
something major changes on the GNOME side. The best that could be done is to ship a fork of GNOME Shell with a large number of (likely quite intrusive and non-upstreamable) patches. This means that users would be stuck with a single GNOME Shell version for an entire Qubes release even if they are using a GUI qube, and that the Qubes team would need to ship a separate package containing both GNOME Shell and any dependencies that needed to be bundled. Using an extension would not help because extensions are also patches to GNOME Shell. The only difference is that they are applied at runtime (via JavaScript) rather than at compile-time.

I think @ninavizz’s suggestion of improving KDE is a much more realistic option. UX improvements will benefit all users of KDE, not just Qubes users, and as such are much more likely to be accepted upstream. KDE is much less opinionated than GNOME, which means that it can be made to fit Qubes OS much more easily. In fact, I believe Qubes OS currently does not need to patch KDE at all.

1 Like

From my experience with KDE it is extremely slow compared to GNOME / xcfe and actions that would be near instant on gnome or xcfe can have several seconds of delay. This is based on KDE in parrotOS, but if KDE in Qubes is anything similar in speed then I doubt the average user would be okay with it.
In my personal opinion I’d much prefer a GNOME fork over KDE

I am not familiar with GUI qubes, what exactly are they?

Can I ask a basic question?

In my understanding the things required from a DE in Qubes OS are:

  1. draw window borders
  2. provide launcher (aka start menu)
  3. some form of taskbar / dock
  4. tray icon area capable of displaying icons from other qubes (network manager etc.)
  5. basic notification daemon

XFCE in its current form integrated with Qubes OS does all of those things quite well. The only additional feature KDE brings is the ‘activities’ and user configurable window positions, which one has to do with devilspie2 in XFCE.

What else is there? Where is this urgent need for another DE coming from?

Work on a better/different start menu is ongoing. We got lots of better icons.

Do people just want more / different themes?

What is the need that makes it so appealing to switch away from XFCE? The ‘expose’ like function in Gnome?

2 Likes

KDE offers some additional features, like moderate tiling support, “show all windows” and so on, that xfce does not. Also wobbly windows is best :laughing:.

Before becoming aware of whisker menu on xfce, the start menu was the thing that brought me to it.

But honestly i think for most people it is just “looks better”. Sure, many Features can be gained by additional software, like whisker menu but i think Qubes has a large group of people not wanting to tinker with how stuff on linux works (yet), rice their environment (yet) and they enjoy the ease of use of KDE with the many build in features.

In my case its that KDE looks and feels modern.

Sure you can customize XFCE to make it look good, but feel is another thing. The animations for instance are not there at all

I must say that whenever I hear “modern” in terms of software, my first association is Fashion TV and how would I feel wearing those “modern high heels”…

2 Likes

I see.

Then allow me to bring in another perspective. Not saying this is how this ought to be, but simply that there are also users with VERY different priorities:

I am a software developer myself and spent the last 30+ years of my life in front of a screen pretty much every day. Topics such as how windows look and feel, how applications are launched, what an email client/word processor/spreadsheet/presentation/ide etc. look and feel like are settled in my opinion. I have not seen any actual innovation in that area for 20+ years.

What I do see is pure madness: applications get bigger and bigger and slower and slower. They don’t get new features but their GUI gets messed with all the time. There is no benefit, just window dressing. Now I hear some people seriously program UI in JavaScript! WTF? Thunderbird utterly destroys something that was working just fine (Enigmail) and replaces it with “new” (less features, who asked for this?)

Bottom-line: I see no benefits and just annoyance. No value, just distraction.

This is why I am so happy with debian stable, XFCE, Qubes OS … Actually Qubes OS is the only ‘thing’ that is still forcing some amount of change in my environment, which I am OK with for the security benefit it provides. Other than that I have to deal with enough change and “new” in the context of my work. Where it belongs.

I have zero appetite to change the rest of my computing experience. It is settled and I am productive. Change to it needs to actually bring a benefit. New for the sake of new … done with that.

7 Likes

I completely emphatize with

I’m not saying qubes should become windows. However you should consider that your specific use case is not applicable to a vast majority of users who don’t have 20 years of experience I imagine most of your daily navigation consists of keyboard shortcuts, as is the case for most other software developers I know, however I don’t think requiring people to be powerusers to easily navigate the system is good. Even after a couple months of using qubes I still struggle navigating the UI whereas debian or ubuntu has sensible shortcuts out the box and menus that are much easier for casual users to navigate. I am not saying qubes should become either of those. I believe the reasoning outlined by the qubes team for favoring the switch to gnome is reasonable.
"## GNOME, KDE, and Xfce

The desktop GUIs that QubesOS versions 1 - 3.1 offer are KDE and Xfce. We are currently migrating towards using GNOME. We know some people prefer KDE, but we believe Gnome is easier to use for average non-technical users. Xfce will always be supported, and technical users will always have the choice to use KDE or other desktop environments."

I believe the current out-the-box Qubes XCFE solution fails to meet almost every requirement regarding cognitive load, Easy to Understand, etc outlined in Usability & UX | Qubes OS at the very least for non-technical users without prior experience or knowledge. Out of the box qubes XCFE is not user friendly at all just right-clicking the desktop gives you 20-something different actions and just going to the qubes specific settings/menus requires navigating a fold-out menu. the navigation by pressing the super key, easy searching, etc speeds up navigation significantly.

Considering I’ve read discussions dating as far back as 2016 discussing I don’t think it’s fair to call it some urgent need Add support for GNOME in dom0/GUI domain · Issue #1806 · QubesOS/qubes-issues · GitHub this has been talked about for over half a decade and I think the reasons provided are pretty solid

No one is arguing that XCFE should be removed, simply that users who prefer GNOME should have that as an option because as described in Usability & UX | Qubes OS most non-technical users prefer gnome and not being able to navigate the system properly is a massive distraction for those users

1 Like

I agree with you regarding applications removing features and drastically changing the UI just for the sake of change.

This is true for GNOME but not KDE. KDE is still very customizable like XFCE but at the same time very user friendly to many users. Although I think Qubes should allow you to choose between the three.

1 Like

I can emphasize with @Sven too.

But here i have another opinion. XFCE may not be pretty, but it sure is easy imo. It reminds me of the win98 start menu, and in a sense it behaves like one might be familiar with windows98.

It offers concise options and naming for things (as opposed to KDE in some regards).

So in my opinion it is easy, but it is not the most comfortable (for example the menu, whisker is much better).

Depends. Having some weird default action when moving the mouse into corners or multiple places where one can create shortcuts sure is irritating for new users coming from windows, but it really is not too hard. It is just different.

That makes sense. For Qubes OS use 95% of what a user does is inside a qube and therefore entirely untouched by the DE. It’s only purpose is to draw the window borders, provide a launcher, a way to navigate open windows and notifications. That’s it!

The current effort to create an application menu that is tailored to Qubes OS as well as to polish the Qubes OS specific tools and dialogs is the right way to go. Changing the DE will have very little effect on it. It’ll look more familiar maybe on the first look, but the same confusion will set in afterwards because things just work a little different in Qubes OS. One has to understand some concepts.

To that end creating Qubes OS specific on-screen tutorials and improving the Qubes OS specific UI and flow actually add value. Switching to another DE doesn’t add much other than “cool”. From everything I read so far, it will be extremely difficult to maintain and add a substantial burden on the development team. In that case: please no!

The problem is that Gnome integration won’t happen (see @Demi’s summary). So either we make XFCE work or switch back to KDE. Again, for the actual work that needs to be done (see above) I don’t think it makes much of a difference.

Have a look at videos showing what good DE can do beyond this: https://pop.system76.com/. Well, technically, you can call it “just navigate open windows”, but it’s a different level I would say.

I wish client-side decorations were possible as @Demi described. (Although I’m not sure I would use something else than default due to security.)

1 Like

That does look neat, but not at the price of lowering security and/or diverting Qubes OS development resources on an ongoing basis (maintenance). Having the Qubes OS team maintain what would basically be a fork of Gnome doesn’t sound desirable to put it mildly. Pretty sure we agree.

The Pop!_OS DE indeed looks really neat. I read that they are currently using Gnome extensions but are not satisfied with them and also have disagreements with the Gnome devs, so now they’re developing their own DE in Rust.(Which will design-wise be the same as the one currently shown in the videos).
If they are open to changing the things that Gnome devs did not want to change, then maybe Qubes can use their new DE. Since they’re developing it, Qubes devs would not need to maintain their own Gnome fork.

2 Likes

I have to disagree with that. Albeit my particular setup with GNOME is pretty hack-y the key Qubes elements don’t have any particular difference that I’ve ran into so far. I cannot stress enough that it ISN’T just "

The concepts are completely unchanged. I agree wholeheartedly with

As mentioned previously, I don’t think it is reasonable to expect the average user to be a power-user. The whole reason Manjaro even exists is because while Arch is great it is also a massive commitment and requires a bunch of troubleshooting. Again I’m not saying qubes should become ubuntu, but there HAS to be made major improvements in usability because otherwise most users will just be turned off and instead go with a much less secure OS. I’ve considered just giving up on qubes so many times because despite how much I like the concept it is a HUGE sink when it comes to productivity. I just do not find it reasonable that after a single day of using ubuntu or debian I can navigate it faster and smoother than I can with XCFE on qubes after months of daily use. And when I switch to GNOME, while I’m still slower than I would be on ubuntu or debian it’s still much more intuitive than XCFE. I obviously have some bias due to having used other distros with GNOME in the past but I still think fsflover is correct.