Is gnome on dom0 possible?

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.

I am talking about the Qubes OS specific concepts of templates, disposables, how to install software, how to copy between qubes etc. Any new user will have to learn and understand these concepts, no matter how familiar everything else looks.

A lot of the stuff modern DE’s come with (widgets, integrated apps, fancy clipboard modes etc.) won’t work and don’t make any sense in dom0 nor sys-gui.

In any case, I feel like I made my points:

  • XFCE does the job, like almost any other DE would.
  • Affinity to this or that DE stems mostly from flashy, eye candy like stuff that is neat but not essential.
  • Real UX improvements that targets new Qubes OS users HAS to come from the core team BY DESIGN. Upstream DE won’t have any idea or interest in those concepts.
  • Gnome would be nice, but not at any cost … KDE is available for those looking for advanced workspace/activity/window placement features
2 Likes

I am afraid any discussion towards DE is pointless, because most probably we will have bigger worry looking at the Qubes development roadmap.

And I wonder how many of those interested in Gnome or any other DE, (or even in QubesOS itself) will click these 3 links and read what’s behind them.

@enmus This has nothing to do with the choice of DE, because dom0 will not run any DE. We already have sys-gui for that. And this is good.

XFCE does the job. But is it efficient and productive enough at managing windows and UX? If not, most people (who do not enjoy managing their computers as hobby or must use Qubes) will choose another OS. Same with KDE.

This is a strawman. We are discussing useful improvements to the DE. They do exist.

UX improvements can come from many sources at the same time, as I demonstrated in my above link to pop!_OS. That functionality would probably already be useful to many Qubes users. Even though you may not trust their DE, many people would (or decide that it’s worth it due to the UX improvement).

This is definitely true. Perhaps the community should help somehow in order to make client-side decorations possible.

Sorry, the topic’s subject is "Is gnome on dom0 possible?, so I carefully replied on that. Which means you agree with me that this discussion is pointless, you just confirmed it. Unlike, I see it as a worry.

In this context, “client-side decorations” means that the decorations would be drawn by the GUI daemon, as opposed to the compositor. The GUI daemon is a client from the window system’s perspective. It does not mean that a VM can draw whatever decorations it wants; that would obviously be bad.

1 Like

Where the desktop environment runs (dom0 vs GUI qube) is largely unrelated to which desktop environment should be chosen. Virtually all arguments that I am aware of apply equally in either case.

Exactly. GNOME is not a bad desktop environment. It is, however, an opnionated one, and this makes it much more difficult for Qubes to make the necessary customizations in a maintainable way. GNOME is perfectly fine for environments that do not require such customizations.

To be clear: If someone were to successfully integrate gnome-shell into Qubes OS, that would be amazing, and at least I would be more than happy to review it. However, I am very skeptical about whether this can be done without an excessive maintenance burden. Furthermore, lots of gnome-shell’s features, such as NetworkManager integration, would either need to be dropped or reimplemented in a Qubes-friendly way. This reduces GNOME’s advantages.

3 Likes

Of course, and this topic is specifically about dom0 and I replied on that fact with

Otherwise, I wouldn’t reply at all. I’m not interested in DE per se.

So I have some sort of idea that I need gnome to be part of the desktop environment of dom0, but gnome has no availability to be in Qubes. is there any ways to develop gnome as the desktop environment and tested out as good DE for Qubes 4.2?

2 Likes

Not really, unless you are willing to implement it yourself and submit a PR with your changes. I do not see the main problem (unstable shell extension API) going away anytime soon.

1 Like

Hi, I developed an extension for gnome-shell to add colored borders.

You can find the extension at Qubes-Coloring-Extension. The extension basically add a St.Bin on top of the window and change the color based on the qube color.

Hopefully, this initial step will lead to a full support for gnome by the great qubes team :slight_smile:

4 Likes

https://groups.google.com/g/qubes-devel/c/MTa7fq0zJ5o

Nice! A quick glance found one obvious issue (use of xprop to get window properties). Other than that, does this work in sys-gui and/or sys-gui-gpu? What happens if there is a fault (unexpected exception) somewhere in the extension? It is better to not display a window at all than to display one with an incorrect color. The ideal solution would be to display the window and the border as a single atomic operation, but if that is not possible, an alternative would be to first draw a window with the same color as the border, then the border, and then the real window.

2 Likes

Yep I agree with you that using xprop is not the best way to get the window prop. Also, getting a qube label using spawn command is bad. However, this was a quick testing to come up with a solution to draw the colored borders. I would think of a better solutions.

Regarding sys-gui and sys-gui-gpu if they can run gnome-shell, I don’t see any issue running the extension on them. Unless you have specific concerns.

During the development a couple of unexpected errors occurred like missing a file or using a null object. The gnome-shell will raise an error and show a message in tweaks or extensions applications. Which requires reloading either by log-out or Alt+F2 then entering r. I think it depends where the error occurred in the code if it occurs before inserting the border in the window stack no border will be drawn.

I didn’t get the idea behind the ideal solution if you could explain more. But currently, the solution creates St.Bin objects and stack them as follow:

stack = [
application_window
st.bin
application_window
st.bin
.
.
.
]

I do not in any way want to change the flow of the topic, as I think it’s awesome to see some progress on maybe making another DE function for Qubes (just because I subconsciously like pretty things, but also very much like the Qubes OS structure and greatly appreciate its goals and incredible work in reaching them), but I just wondered if the Cinnamon DE might have made any useful changes to Gnome’s “opinionated”-ness that could be leveraged to customize border colors or something. I speak almost entirely in ignorance, but just as someone who knows Cinnamon was built on modification of Gnome, and who also just really likes using Cinnamon and knows its quite popular as well. The more traditional layout menus also remind me of how Qubes has XFCE set up right now, with the list of VMs that expand out to applications specific to each, so it seems like similar functionality in general could be obtained at least for the end user’s side (not necessarily behind the scenes, as I am discovering reading this post, though?).