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.
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
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.
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 @Demidescribed. (Although I’m not sure I would use something else than default due to security.)
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.
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
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.
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.
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?
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.
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
