Does anybody know whether it’s possible to run gnome as my primary desktop environment? I couldn’t find anything on this besides https://github.com/QubesOS/qubes-issues/issues/1806.
For a long time there has been the intention to move to gnome due to its user-friendiness:
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. (source)
So that should be comforting to hear. However, that intention is limited by the technical challenge of actually modifying gnome to support Qubes (specifically the colored borders). As far as I’m aware all the progress made in that direction has been made mainly by external contributors on their free time and all of that is documented in the GitHub issue you mentioned.
Currently there is quite a big bounty to be given to whoever manages to implement said functionality.
https://www.bountysource.com/issues/31778112-add-support-for-gnome-in-dom0-gui-domain
Last but not least, a student recently showed interested in working on this for Google Summer of Code. So assuming he/she is the selected candidate for mentionship, that project may move forward:
https://www.mail-archive.com/qubes-devel@googlegroups.com/msg04823.html
4 Likes
That sounds very promising! I’ll be looking forward to potentially beta-testing gnome on dom0 
2 Likes
I can’t wait for Gnome in dom0 especially the ability to press “Super” key and see all the open windows. Would be great if anyone know how to implement that in xfce environment in dom0.
1 Like
There is a tool called Skippy-XD that does what you want, but
unfortunately it’s not available from the standard repo. So you would
have to build it yourself preferably in a Fedora-25 qube and then move
it to dom0.
1 Like
Well yeah, thank you @ninavizz for summoning a core team member. 
Let me be clear:
-
XFCE does not have this ability
-
Skippy-XD is not available from a trusted source (Fedora project) and if you audit/build it yourself it’s all on you. So: bad idea. Don’t do it.
-
If you really need this function in your life now, install KDE (see @unman’s post)
@Demi: I repent!
1 Like
Didn’t so much summon Demi as a core team member; more, that she’s had her head wrapped around getting to the bottom of this, for some time. Kierkegaard is about the only source she has not yet consulted on the topic, if I’m being completely honest. 
I’ve been advocating for GNOME based on what I know of its UX patterns, having only looked at online static reference material, read posts on their user research and design efforts, etc. I have a Linux laptop, finally, and have yet to find the time to commit to properly messing around with GNOME against KDE to see for myself what the UX superiority delta really is.
That said, Demi has also made it pretty clear that GNOME would be a not-insignificant amount of work for Qubes OS Project to maintain, for lots of reasons—most having to do with security, hypervisor, or window coloring needs. Project sustainability also matters, and it well could be cheaper for Qubes OS Project to fork KDE and customize-in the consistency/usability stuff I’ve been hoping to get from GNOME. Until Qubes OS finds its multi-million dollar benefactor, Qubes gotta prioritize sustainability things, meethinks, above all else.
1 Like
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:
- draw window borders
- provide launcher (aka start menu)
- some form of taskbar / dock
- tray icon area capable of displaying icons from other qubes (network manager etc.)
- 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 
.
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