Add support for GNOME in dom0/GUI domain

[marmarek]

Tasks here:

• [ ] window decoration (colorful frames)
• [ ] stripping unneeded components (file manager, automounting devices etc)
• [ ] adjusting application menu
• [ ] Qubes Manager integration (whatever it means)

[mr-sour]

So I'm going to try to take a stab at codifying what the gtk inspector does, https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/inspector/css-editor.c#L267 More specifically I think I just need to get the current GTK display object for the window in question, create a new style provider, and then load whatever custom style sheet we want for that window (title decoration, borders ect...) the only thing thats kinda open ended is how to go from xid/xprop -> gtk display object but I'm sure theres a way to relate one to the other. When I get into the details I'm hoping that I can avoid using gtk3-devel but its probably not the end of the world if it includes the necessary private functions that dont ship in the regular gtk3 package. Sorta back at square one but its not like I had allot of time into making COGL render a border anyways.

Also I dont think I'm well versed enough in qubes internals to figure out how to set qubes-guid --title-name Maybe I was doing it correctly and it wasn't working but I suspect the more probable cause is user error. I thought I was punching in everything correct but then I got to domid<=0? [test@dom0 ~] and realized there might be more steps is there a developer guide somewhere that I missed that explains it how you invoke it to open/set a window with the specified options? some hand holding would be appreciated :smile:

[mr-sour]

So I started from scratch and made a GTK module. This module then attempted to add a style provider like so Gtk.StyleContext.add_provider_for_screen and despite setting the priority to uint.MAX it would not set styles on applications that get there decorations from mutter. (so I've done a 180 and now have something that only works with CSD apps). I know it loads on every application because I was able to make do things like set the title, but decorations seemed beyond my reach. I tried several other methods from the API in the module and all I was doing was pretty much adding extra steps. Plus GTK modules support is being dropped in GTK4 so this would have to be re done anyways even if it worked.

I think long term the best solution that was mentioned awhile ago is to setup gui-daemon to use client side decorations. In gnome it would have the ability to just draw its own decorations and in other desktop environments where it doesn't detect CSD support it would just fallback to how it currently works. But after looking at it thats probably easier said then done! Theres still other options but I imagine it would be more work for no benefit. Since its currently is using x11 to create a window I would suspect wherever the window is getting created it might be possible to use GTK instead and then have GTK pass the x11 window resource back minimizing how much needs to get updated I'll look into this later as I get more familiar with how it works

As a temporary solution I'm going to try something that I discovered going though all this GTK stuff but I know it isn't ideal. Themes currently support variants, these variant can be set though XPROP and decorations from both mutter and csd apps will use those styles. I'm going to just take the default theme and then abuse the variants system to add the decorations. It sucks because it means any new theme will need corresponding variants patched into it. Not to mention if the theme you want to set is a variant you would need to make a variant of a variant. Hardly an ideal experience. But I'm sure this can be automated and it wouldn't be that bad.

[mr-sour]

Just kidding! I got the module to work. There is no documentation everything I've read says it shouldn't work, and every issue that related on the gnome tracker/mailing lists is generally met with the sentiment "rework your application". But can't argue with results. We'll still have to revisit it when gtk4 becomes a thing down the road but its not out yet and from what I've seen so far is that for it work in GTK4 it will almost certainly require qubes-guid to present itself as a CSD application and provide its own decorations. Edit: by working I mean I got custom providers to apply to all windows. Theres still work like getting the X properties associated with the window to make it functional. This seems to not be straight forward as right now I can only get this info for windows in dom0. I suspect the fact that GUID making the window directly in X is making it sorta tricky as xterm also isn't working.

[mr-sour]

well I think I'm back to just adding the changes to qubes-GUID. The module has issue that I dont think can be overcome. to attach a style provider I can load it for the whole screen or attach it to a single widget. The screen is global so everytime you open a window it will set all the window colors to that window. getting the widget for the titlebar as far as I can see is impossible with the objects available. theres no methods available to list widgets of a GDK.window object which is what mutter is using to draw the frame decorations. If it was a GTK.window thats available but GDK is a much lower level api and it doesn't look like theres anything of the sort. Now according to random people on the internet using that set provider for screen option should only apply to your application which is why I thought this was worth while but in this context the application is mutter, and all decorations drawn by mutter. There is some stuff I thought of that could make it work but its already kinda getting into the weeds so I think I'm gonna cut my losses, plus allot of the stuff I thought of would probably add more complexity then trying to modify qubes-guid to present CSD decorations. I think this shouldn't be to bad if my plan of making a gtk.window and then getting the x.window handler for it and passing that back works. Wont know till I try!

[mr-sour]

My plan of simply creating a gtk window and then passing the xid back to the rest of the application I dont think is gonna work because of gtk event loops and the normal apps event loop conflicting. I started experimenting but it was super busted and the rendering was all kinds of messed up. It looked like the gtk window was pretty much rendering on top of the x11 window but if you waited long enough it would eventually refresh and you could see the x11 window that was supposed to be there.

So I took to a different approach. (anyone counting? :smile: ) I found Xembed support in gtk and wondered if I could embed a X11 window into a gtk window and see if that avoid all those issue. I started with using something that supports gtk sockets as that was really easy to use. I eventually moved on to creating a simple x11 window and then passing the xid of that new created window to my gtk socket interface and it looks like that actually works without any issues. I'm take this approach to qubes GUI-Deamon :crossed_fingers: and hope it works. I believe it can even be coded in such a way where this window embedding can be turned on and off very easily as to not effect the integration on window managers that dont support csd.

[marmarek]

In practice, SSD is done with very similar thing - the decoration is a separate window (in x11 terms) that is wrapping the actual application window (this is also called reparenting window manager).

Just be careful about system tray icons - those gui-daemon itself sends into tray using Xembed.

[demeralde]

Would really like to see this. Qubes's GUI is one of the main things that's stopped me from switching over from Ubuntu. UX is important and I'm personally not a fan of the default one.

[unman]

On Sat, Sep 19, 2020 at 03:34:47AM -0700, Daniel Spajic wrote:

Would really like to see this. Qubes's GUI is one of the main things that's stopped me from switching over from Ubuntu. UX is important and I'm personally not a fan of the default one.

Switch over to KDE : far nicer than Xfce, and much measier to work with.

[demeralde]

@unman unfortunately I'm not a fan of KDE either. I really like GNOME and have grown used to it. I'd still consider switching, though.

[mr-sour]

@dspacejs you and me both! I'm working on this as time permits. I think I'm on the right track but Im no expert in any of this stuff so development is slow as I have to figure out allot of stuff before even small pieces start working. But I'm hoping after this decoration task its all downhill from there.

[johannesrld]

same here, but im wondering why the first solution to the colour problem wasn't used, it shows you what vm you're using without destroying GNOMES CSD, if you want to show what vm you're running you could show it in the top bar alongside the name of the application like gnome already does?

[jonkri]

The bounty just increased by another $100. Thanks, woodrad! :slightly_smiling_face:

[demeralde]

@jonkri what bounty? Where? I didn't know people earn money to do open-source work

[jonkri]

@dspacejs: Hi! :slightly_smiling_face: Here's the link: https://www.bountysource.com/issues/31778112-add-support-for-gnome-in-dom0-gui-domain.

[lattice0]

Donated 5 bucks, @jonkri. Not much because it gets multiplied by 5 in my currency. Thanks for the work guys, I'll love to use gnome on Qubes. How far is this transition? 3 months away? 5? 1 year?

[uohmak4fvpqe]

Hi, just wanted to let you know I'm also waiting for this to happen. Thanks for the work being done here

[wendivoid]

Thanks So much for all the work that's gone into Qubes so far. I've been waiting for this to use Qubes permanently. I'd like to contribute if possible but i have some ideas and questions first.

I think it would look much better if instead of trying to color the window decorations based on witch VM the application it is running in, it could simply set the GTK theme in the Qubes Manager Application for each VM. I don't know much about how qubes gui protocol works but wouldn't this mean the dom0 GUI could simple not render decorations at all and pass a completely transparent window down to the Sandboxed application witch would be rendered with the GTK theme in the VM config?

I think this approach would break less GTK themes (discolored invisible text & what not) witch is a big plus for non techey people being able to easily customize and personalize. I know QubesOS isn't really about 'looking nice' but i think thats important in getting more people to adopt it.

My main question is i cant find the discussion on this, is there some reason why this solution would not work? Or where would be the best place to discuss this if not here?

[marmarek]

it could simply set the GTK theme in the Qubes Manager Application for each VM

No, this won't work for a very basic reason: application running inside the VM must have no influence over its decoration (or whatever other means we use to mark from which VM given window is). This means, it must be dom0 (or GUI domain) who draws the decoration. Otherwise VM application could lie about its origin.

[wendivoid]

No, this won't work for a very basic reason: application running inside the VM must have no influence over its decoration (or whatever other means we use to mark from which VM given window is). This means, it must be dom0 (or GUI domain) who draws the decoration. Otherwise VM application could lie about its origin.

Ah this makes sense. I'll keep researching into this for now.

[deeplow]

Not sure if this contributes to the debate but apparently Gnome allows for some crazy border related things. This guy made a vortex-like animation w/ the border through css.

[partipan-dot]

Hey everyone! I'm working at this at the moment/trying to find a solution that works. As far as I understood the conversation up until now we have to patch mutter or the qubes guid windows processes (qubes-guid). Is this correct? For me patching mutter looks cleaner. But isn't adding CSD to qubes-guid easier? I think I'm missing something here. I'll research both a bit before deciding which part to patch.

[marmarek]

Regarding CSD for qubes-guid - yes, this could be a good solution, but there may be some traps too: https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-547698664 Also remember that qubes-guid may not become gnome-only application (it doesn't exclude CSD, just something to think about when implementing this).

[mr-sour]

I've picked my work of re-parenting x11 windows into gtk windows (adding csd support to qubes-guid). while my little demo app made it seem easy enough there's some bits I would like to share in case my life picks up again. Since qubes guid runs its own event loop. The typical gtk_main() call is blocking so thats gonna need to get spawned into its own thread and everything gtk related will need to be thread aware (which is supported just more work :smile: ). more pressing issues in my builds include lovely X11 errors like "invalid PMaxSize" "XShmAttach failed". I believe that's mostly caused by when the windows get re-parented qubes guid then has invalid references to them and then things start going south when it does anything with those objects.

Once I fix those issues GTK could also have similar issues. If that ends up being the case and things start looking bad in terms of gtk and x11 calls co-mingled all over the place I'll probably look at wrapping all those X11 calls into new functions that can use either the x11 call or a gtk call depending on the window environment (functions from gtkx.h instead of Xlib.h).

Also to date my efforts have been focused on GTK as my original efforts involved GTK modules and interacting with gnomes extension system. With implementing CSD support within qubes guid its possible to use any framework to implement the decorations. So even if using GTK looks like more trouble then its worth, other frameworks might be more compatible with integration into a vanilla X11 app. I'm not going to investigate that as I suspect the issues I'm running into you would run into implementing any GUI framework into guid so its really just picking your poison. Plus the obvious alternative is QT but they use c++ and I think its best to just have everything be C.

also to answer @tauin and @deeplow belatedly. both of those decorations were done with a gtk module which i looked into and hit a dead end. I'll spare you a novel and just say it would have been super jank and things are fragile enough as is.

[marmarek]

Since qubes guid runs its own event loop.

The main loop is trivial and can easily be integrated with any event loop that supports registering a callback for readable file descriptor - which is basically any event loop. Just take the FD with libvchan_fd_for_select() and register handle_messages() as a callback for it. This should avoid the need for threads.

void handle_messages(Ghandles *ghandles) {
    libvchan_wait(ghandles->vchan);
    while (libvchan_data_ready(ghandles->vchan)
        handle_message(ghandles);
}

lovely X11 errors like "invalid PMaxSize"

Should be safe to ignore - some VM applications set absurd values here and we simply ignore them.

"XShmAttach failed"

That's more worrying. If you get that from time to time only, then it may be related to a window that no longer exists in the VM. But if you get that for every window, then something is wrong. qubes-guid needs to read /var/run/qubes/shm.id.0 - maybe that failed? Another reason indeed may be related to interaction between raw X11 calls with GTK. The details attached to that error message may shed some light.

[DemiMarie]

@ninavizz How much would using GNOME improve UX over using XFCE or KDE? Serious question.

[uohmak4fvpqe]

@ninavizz How much would using GNOME improve UX over using XFCE or KDE? Serious question.

Well, serious answer : using GNOME improves experience of those who prefer GNOME

[DemiMarie]

@ninavizz How much would using GNOME improve UX over using XFCE or KDE? Serious question.

Well, serious answer : using GNOME improves experience of those who prefer GNOME

Perhaps a better question would be, “What fraction of users (especially non-technical ones) prefer GNOME?”

[jonkri]

GNOME is the default desktop environment in all major GNU/Linux distributions. So it's obviously very well liked and popular.

Due to GNOME's popularity, a lot of people are used to it, so having Qubes support for it would ease the transition to Qubes for these users.

I would also like to note that a lot of technical users (including me) prefer GNOME as well.

[unman]

On Tue, May 18, 2021 at 03:17:52AM -0700, Jon Kristensen wrote:

GNOME is the default desktop environment in all major GNU/Linux distributions. So it's obviously very well liked and popular. And a lot of people are used to it as well. I would also like to note that I'm a technical user that prefers GNOME.

GNOME is obviously very well liked and popular, because it is the default desktop environment in all major GNU/Linux distributions. ftfy It wasn't technical supremacy that gave IE 95% market share.

[andrewdavidwong]

I reckon we should see which one best fits Qubes' unique nature. General popularity among other distros doesn't necessarily make something a good choice for Qubes, since other distros don't have to contend with, e.g., unifying a multitude of compartmentalized security domains on a single desktop.

[jonkri]

On Tue, May 18, 2021 at 03:17:52AM -0700, Jon Kristensen wrote: GNOME is the default desktop environment in all major GNU/Linux distributions. So it's obviously very well liked and popular. And a lot of people are used to it as well. I would also like to note that I'm a technical user that prefers GNOME. GNOME is obviously very well liked and popular, because it is the default desktop environment in all major GNU/Linux distributions. ftfy It wasn't technical supremacy that gave IE 95% market share.

Regardless of why GNOME is well liked and popular, it's well liked and popular. :slightly_smiling_face:

Also, all these distributions presumably had good reasons for making GNOME their default desktop environment.

[jonkri]

I reckon we should see which one best fits Qubes' unique nature. General popularity among other distros doesn't necessarily make something a good choice for Qubes, since other distros don't have to contend with, e.g., unifying a multitude of compartmentalized security domains on a single desktop.

Good point.

On the other hand, I do believe that offering a GNOME option would attract significantly more users to Qubes. I don't know if attracting users is a priority for the Qubes project, though?

For me personally, not being able to run GNOME is the main reason for not using Qubes more.

[jonkri]

Wow, the Bountysource issue has increased to $6,400!

[unman]

On Tue, May 18, 2021 at 08:51:36AM -0700, Jon Kristensen wrote:

I reckon we should see which one best fits Qubes' unique nature. General popularity among other distros doesn't necessarily make something a good choice for Qubes, since other distros don't have to contend with, e.g., unifying a multitude of compartmentalized security domains on a single desktop.

Good point.

On the other hand, I do believe that offering a GNOME option would attract significantly more users to Qubes. I don't know if attracting users is a priority for the Qubes project, though?

For me personally, not being able to run GNOME is the main reason for not using Qubes more.

Of course attracting users is important. If I wanted the security provided by Qubes I cant imagine that the absence of Gnome would be a blocker. If I needed the security, it definitely would not be.

I cant remember when (if) I used Gnome. In my opinion, KDE is the best fit for Qubes - it's easy to customise the menu, trivial to set Activities to match security domains, easy to force qubes to the right security domain, easy to configure keyboard shortcuts etc etc. This puts it streets ahead of Xfce, and it is fully supported in Qubes now (bar one missing icon) What is it that Gnome would bring to Qubes? (Other than having Gnome)

[DemiMarie]

In my opinion, KDE is the best fit for Qubes

Qubes OS used to use KDE, but switched to XFCE before I joined ITL. What was the reason for that switch?

[DemiMarie]

This puts it streets ahead of Xfce, and it is fully supported in Qubes now (bar one missing icon)

Which icon is that?

[andrewdavidwong]

Qubes OS used to use KDE, but switched to XFCE before I joined ITL. What was the reason for that switch?

Have a look at #2119.

[ninavizz]

I personally like Gnome a lot, for general usability, flexibility while retaining a high bar for usability, and consistency. But, I say that having never looked at #2119. XFCE is "highly customizable" but often that comes with usability as a tradeoff—which as is the case with XFCE and Libre Office, I believe to be the case. Both for developers customizing things, and end-users customizing things.

Joanna's citations of system bloat/load and general ugliness, I think we can all agree on as bad for KDE.

BUT, as I'm working on new custom and Qubes specific widgets, it would help inform my work a LOT if the core team could make a decision of some sort on the Gnome point. Whether it's an aspirational goal (likely) or an immediate one (unlikely). I am currently modeling a lot of my stuff on Gnome components, because they're well resolved and that frontloads a lot of user research into usability, on my end.

If all of the above is just really distracting or otherwise upsetting to folks more familiar with long-term issues than I, please feel free to ignore. :)

[DemiMarie]

BUT, as I'm working on new custom and Qubes specific widgets, it would help inform my work a LOT if the core team could make a decision of some sort on the Gnome point. Whether it's an aspirational goal (likely) or an immediate one (unlikely). I am currently modeling a lot of my stuff on Gnome components, because they're well resolved and that frontloads a lot of user research into usability, on my end.

How much would the decision of desktop environment impact the UI design?

From my perspective, if GNOME is the most user-friendly desktop environment, it should be the default. However, it also appears that it would be a very large amount of work, mostly because of its lack of customizability.

[ninavizz]

From my perspective, if GNOME is the most user-friendly desktop environment, it should be the default. However, it also appears that it would be a very large amount of work, mostly because of its lack of customizability.

Customizability for the Qubes team, or for end users? For end users, I don't see that as a problem, tbh. While that is what many hardcore libre-types and longtime Linux users desire, it's not what "regular" computer users either desire or are accustomed to (which I'd also suspect to be a reason why the Gnome team opted for that, if that is the case).

If it's for the Qubes team, obvs that's a different story and I'd love to take a deeper look into this as our cycles grant us the time.

[ninavizz]

Like—of all the Linux distros, Gnome and Canonical/Ubuntu thus far seem the most invested in making things usable with user research and resourcing regular design contributors. That matters a lot to me when trying to bootstrap off existing projects, and looking at where to pick from.

[DemiMarie]

If it's for the Qubes team, obvs that's a different story and I'd love to take a deeper look into this as our cycles grant us the time.

I suggest asking @marmarta ― she is the one who has done most on the work in this area, IIRC.

[andrewdavidwong]

@marmarek, is https://github.com/QubesOS/qubes-issues/issues/1806#issuecomment-280281571 still accurate?

[marmarek]

Kind of. I (or some other team member) can help with review or helping with some design choices, but likely won't spend much time with more engaging work like testing or debugging before releasing 4.1.

[unman]

On Tue, May 18, 2021 at 02:42:29PM -0700, Nina Eleanor Alter wrote:

I personally like Gnome a lot, for general usability, flexibility while retaining a high bar for usability, and consistency. But, I say that having never looked at #2119. XFCE is "highly customizable" but often that comes with usability as a tradeoff???which as is the case with XFCE and Libre Office, I believe to be the case. Both for developers customizing things, and end-users customizing things.

Joanna's citations of system bloat/load and general ugliness, I think we can all agree on as bad for KDE.

BUT, as I'm working on new custom and Qubes specific widgets, it would help inform my work a LOT if the core team could make a decision of some sort on the Gnome point. Whether it's an aspirational goal (likely) or an immediate one (unlikely). I am currently modeling a lot of my stuff on Gnome components, because they're well resolved and that frontloads a lot of user research into usability, on my end.

If all of the above is just really distracting or otherwise upsetting to folks more familiar with long-term issues than I, please feel free to ignore. :)

bloat? Perhaps, but I'm not convinced.. Load? I just cant agree. KDE runs just fine on low powered machines, as has been confirmed by many users. Last time I did any sort of comparison I found it on a par with Xfce. Gnome has a higher RAM usage. Ugliness? Cant really comment: It's not a common criticism. The fact that Gnome has spawned so many forks suggests that users aren't so taken with the look.

[unman]

On Tue, May 18, 2021 at 05:32:17PM -0700, Nina Eleanor Alter wrote:

From my perspective, if GNOME is the most user-friendly desktop environment, it should be the default. However, it also appears that it would be a very large amount of work, mostly because of its lack of customizability.

Customizability for the Qubes team, or for end users? For end users, I don't see that as a problem, tbh. While that is what many hardcore libre-types and longtime Linux users desire, it's not what "regular" computer users either desire or are accustomed to (which I'd also suspect to be a reason why the Gnome team opted for that, if that is the case).

If it's for the Qubes team, obvs that's a different story and I'd love to take a deeper look into this as our cycles grant us the time.

Nina - I guess you've never worked in IT support. If there's one thing that "regular" users love it's customising their desktops.

[ninavizz]

Nina - I guess you've never worked in IT support. If there's one thing that "regular" users love it's customising their desktops.

I have not ever worked in IT—but we've (the UX community) studied that phenomenon with user research, for years.

Everyone "wants" what they want. That doesn't mean what they want is the best solution for their host of needs, though. Kids would eat nothing but candy if they could, because their tastebuds haven't developed to recognize much but sweet flavors. And yet if we let them eat nothing but sugar, they'd get malnourished and drive us to the point of murdering them with their resulting rambunctiousness. User Research is a discipline, for this very reason. Otherwise we'd just always ask users "What do you need?" and build according to their literal answers. That's how the world got the Pontiac Aztec. Very functional, but dreadfully ugly and a lot of functionality for some users, mushed in with functionality for other users—trying to make everyone happy, while effectively making only a very few fringe consumers, happy.

Keep in mind, too—IT departments configure things to be easily updatable by y'all and to conform to standards that make it easier for y'all to support many folks. That likely is not how folks have their home computers setup, and it would be easier for them to do some basic customization—a familiar wallpaper, and desktop tooling behaving similarly to how their home computers behave. For security and for maintainability, y'all just can't allow a lot of that. Which points to the hierarchy of needs to make a product suit it's true use. Try to suit everyone, and you'll end up suiting nobody.

The "Customization" XFCE offers is above and beyond what a usable system should offer, on an aside; and none of it (as well as none of Libre Office's customization) helps facilitate core usability. Only "user preference" among dozens of marginally usable options. It also offers default settings that developers love, and I suspect confuse or overwhelm more passive "normal" everyday users. So for it, the customization is necessary to get a non-obnoxious experience.

An important component to UX is learning what people want, out the gate—and from there, what they'd like to add on. The whole point with my AppMenu survey, is to get that kind of feedback around the myriad of features that could go with a new appmenu, or not.

MySpace was famous for offering endless customization, to the point that users made their own experiences with the product unusable. And yet to regular folks, they don't have the skill to recognize that.

All of the above, TL;DR is to say that offering some customization is great—but that what customization is offered, needs to be carefully studied and shaped in such a way, that it never compromises the core usability of a product.

Again, Gnome has had UX folks contributing to it for years. XFCE I do not believe has. That alone, has me trusting Gnome ahead of XFCE, out the gate. They fundamentally care about UX, whereas XFCE I don't see the same from. Whiskers, as a great example, is packed with great intent and yet easy to avoid UX mistakes that if a UX contributor had been contributing all along. It's also (as is all XFCE tooling, and all LibreOffice tooling) just a very busy UI—its elements are too busy by-design, because developers don't know how to make things that are not busy and are elegantly modular. Just like designers "can" write code, but could never code a product to function well. So, my biggest gripe with XFCE, is that I fundamentally don't care how customizable a thing is, if all of the customization options are wrong or force met to choose among a bunch of differently-painted "things" that are all put together poorly, from the outset. If that makes sense.

OK, that was a bit of a design lecture. Oops. :D

Also @unman I specifically cited Joanna as the origin of those comments I made on KDE, because 5 years ago I suspect they were accurate. The "Ugly" flag with KDE, is that in the old Qubes screenshots, it's a fundamentally awful UI to have to visually navigate. That matters. That's not about aesthetic preferences, but about shitty design.

[DemiMarie]

@marmarek: would it be reasonable to milestone this for R4.2? It really is important, IMO. @ninavizz: would you be willing to see if KDE has improved since Joanna’s post? Because if it is now on par with GNOME, we can just switch to it.

[ninavizz]

The fact that Gnome has spawned so many forks suggests that users aren't so taken with the look.

This, I would disagree with. "Desktop Themes" are a thing in the Linux world. They are not a thing in Windows or Mac universes. Gnome is a terrific base system, that is highly malleable. It does not call attention to itself. It's also much easier to extend or to tweak, than other systems, for all the reasons its UX team has made it awesome. Linux folks just love to fork and customize everything, so I honestly see its constant forking as more of a win in its favor, than any kind of a detraction.

@DemiMarie This sounds like a big-deal feature to test and to get right—and also a significant user-adaptation change. The AppMenu, also is both. From users, we've heard a lot of frustration with releases taking soooo long. I'd honestly rather earmark this for 4.3, so that 4.2 can be just for the new AppMenu, the new AppMenu preferences panel, and possibly a custom XFCE theme just for QubesOS—with a bunch of new colors for qubes. Of course, a few other things Marek may want (she says, realizing Marek probably already has a lengthy list of core/system things to go out with 4.2). To me, 4.2 is already a big enough user-facing release.

Then, we let users get comfortable with all of that, and THEN in 4.3 plop an entirely new DE on them with either Gnome or KDE. I'd love to see Qubes peeps get more comfortable with radical-discipline combating release-bloat, so that we can push releases more often. Which, I also say, as the queen of feature-creep. Not as a finger-waggy criticism I look down upon others, saying.

Separately: Yes, totally willing to look into KDE... but I also think Gnome would be a much better choice for users. For sooo many reasons. Namely, 1. It's a well-funded project that has had a regular UX team contributing for some time to a product, and 2. KDE is a more ragtag project, and I don't think has had any robust UX contribution to it. Like, their entire HIG appears to have been written by developers trying to self-learn UX; from a wonderful source, Bob Baxley, but it really all misses the point of UX. Projects that see their end outputs as true "products," feel rare in the Linux world. Which, I say as both a UX person, and an anti-Capitalist anarchist.

Gnome being an overall more well-considered product I feel makes it a far more adaptable, well-considered "system." It's more than just a bunch of UI things, it's a truly modular system, with its modularity designed to consider end user needs—not just development needs. Considering how many fully custom Qubes widgets need to be created and maintained in the long-run, for THAT reason I also feel it's much better for Qubes. That said, I'd love to understand the interest in KDE, more.

[unman]

OK, that was a bit of a design lecture. Oops. :D

That was interesting, and "Oops" unnecessary. My comment simply addressed what was perhaps a throwaway remark of yours.

Personally, (as you may have gathered), I don't encourage beginners to do any customisation, and I hide the tools that encourage them to do so. Nor do I focus on templates and qubes. Those things can come later. I focus on the "what" of Qubes, not the "how". I find this best for complete beginners, and I find that KDE allows for strengthening of Qubes use.

As I have said before, the Qubes community has many members whose reach exceeds their grasp. They are able to work with Qubes and that's good. They have struggled with and mastered templates and qubes. Asking them what Qubes should look like, will result in a solution that brings those things to the front. (We saw exactly this around the removal of the Qube Manager in 4.0) There is another way, which will be more immediately appealing to beginners.

Also @unman I specifically cited Joanna as the origin of those comments I made on KDE, because 5 years ago I suspect they were accurate. The "Ugly" flag with KDE, is that in the old Qubes screenshots, it's a fundamentally awful UI to have to visually navigate. That matters. That's not about aesthetic preferences, but about shitty design.

I realised that those were Joanna's remarks, and I thought you were agreeing with them "as bad for KDE". I wanted to give a newer perspective. I have no view on ugliness, but I do not find the design "shitty". As I have said it works extremely well for Qubes.