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)

[unman]

On Thu, May 20, 2021 at 01:52:33PM -0700, Nina Eleanor Alter wrote:

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.

I think this misses the point. Many of the forks, like Mint, were made because users did not like the way that Gnome had developed. Mint was a fork of Gnome 2 in response to Gnome 3. Cinnamon is a fork of Gnome 3 which keeps the Gnome 2 desktop interface. All that UX research didn't meet with user approval. So there's a lot to consider.

[DemiMarie]

@ninavizz thoughts?

[ninavizz]

So... I just re-reviewed the long and rocky history of GNOME. I honestly have no idea when their investment in UX began (tho I suspect it's something like "the last 10 years," and I've never used a Linux machine as a daily-driver; nor do I have a Linux machine I can actively play with. Which is a big problem. Before I form a concrete opinion, I'd like to be able to get an inexpensive/basic laptop, to fuss around with both Gnome and KDE on. I also need Yet Another Linux machine, to use as a Qubes test machine, lol. So glad they're all cheaper than Macs! :)

I don't consider @unman's summations above, to be trivial. BUT, I've only read things to date from FOSS community folks. To Amish communities, a zipper is considered "radical new technology;" so, strong feelings can always be quite subjective, based on the contexts folks are accustomed to. People use Qubes not because they're Linux folks, but because they need the unique security properties; so, Anabaptist vs Catholic traditions, is kinda missing the point when "salvation" is a person's only goal. Even tho, yes, many of today's users do come from Linux. No, I am not the slightest bit religious. Just into comparative religion, and that felt like an apt analogy. Walking away from that one with hands up in the air, though.

Separately, in an ideal universe (when a few million bucks falls from the sky) much of Qubes' DE should be custom to Qubes. Using a hypervisor system requires a totally different mental-model for approaching overall computer use, than using a single-environment system. Doubly so, when you factor security domains and security thinking into stuff. The fact that today's DE has a "Domains Widget" as a separate thing from its "App Menu," is an artifact of all existing Linux DEs being built to support mental-models of single-environment systems—as one example of the mismatch. Same, with XFCE's window decoration options not working with Qubes painting its windows any of an array of colors, based on domain; while also limiting opportunities to add icons and other window frame decoration, to things.

Beyond the appmenu, I'd love to be able to also see the Task Bar customized to Qubes; so each qube has its own dropdown available in the task bar, and open/hidden windows are organized by qubes. The Updater, Backup Manager, and Device Manager, also need not-insignificant improvements to be more usable. Windows Management also could use some more customization to suit Qubes. I'm about to embark on a Policy Manager, and eventually supporting more Salt stuff for less-techy folks, will be important.

Which DE (Gnome or KDE) is best suited to extend with multiple custom components, is a big deal to me. @marmarta is better suited to speak to that.

I promise I'll respond to this thread tho in a few months, with my "UX person thinks this" $0.02, once I have had a chance to spend some time with both KDE and Gnome, tho! Really, this does matter a lot to me. :)

[unman]

On Fri, May 21, 2021 at 12:08:56PM -0700, Nina Eleanor Alter wrote:

So... I just re-reviewed the long and rocky history of GNOME. I honestly have no idea when their investment in UX began (tho I suspect it's something like "the last 10 years," and I've never used a Linux machine as a daily-driver; nor do I have a Linux machine I can actively play with. Which is a big problem. Before I form a concrete opinion, I'd like to be able to get an inexpensive/basic laptop, to fuss around with both Gnome and KDE on.

I don't consider @unman's summations above, to be trivial. BUT, I've only read things to date from FOSS community folks. To Amish communities, a zipper is considered "radical new technology;" so, strong feelings can always be quite subjective, based on the contexts folks are accustomed to. People use Qubes not because they're Linux folks, but because they need the unique security properties; so, Anabaptist vs Catholic traditions, is kinda missing the point when "salvation" is a person's only goal. No, I am not the slightest bit religious. Just into comparative religion, and that felt like an apt analogy. Walking away from that one with hands up in the air, though.

Separately, in an ideal universe (when a few million bucks falls from the sky) much of Qubes' DE should be custom to Qubes. Using a hypervisor system requires a totally different mental-model for approaching overall computer use, than using a single-environment system. Doubly so, when you factor security domains and security thinking into stuff. The fact that today's DE has a "Domains Widget" as a separate thing from its "App Menu," is an artifact of all existing Linux DEs being built to support mental-models of single-environment systems???as one example of the mismatch. Same, with XFCE's window decoration options not working with Qubes painting its windows any of an array of colors, based on domain; while also limiting opportunities to add icons and other window frame decoration, to things.

Beyond the appmenu, I'd love to be able to also see the Task Bar customized to Qubes; so each qube has its own dropdown available in the task bar, and open/hidden windows are organized by qubes. The Updater, Backup Manager, and Device Manager, also need not-insignificant improvements to be more usable. Windows Management also could use some more customization to suit Qubes. I'm about to embark on a Policy Manager, and eventually supporting more Salt stuff for less-techy folks, will be important.

Which DE (Gnome or KDE) is best suited to extend with multiple custom components, is a big deal to me. @marmarta is better suited to speak to that.

I promise I'll respond to this thread tho in a few months, once I have had a chance to spend some time with both KDE and Gnome, tho! Really, this does matter a lot to me. :)

I don't see this as in any way a priority, so pushing it down the line is fine.

Some Amish do object to zippers but not because they are "radical new technology;". In fact there are various of the Amish who do use zippers. For those that don't, it is, I think, because they prefer to make the things they use, and they object to things that may be used to lead to separation in the community. Old Order Amish prefer hooks and eyes to buttons too, for the same reasons.

[DemiMarie]

I wonder if we can use features developed for Flatpak integration here. Flatpak brings an Android-like security model to desktop Linux: applications are sandboxed by default, and an application being able to escape its sandbox is considered to be a security vulnerability. This is a very similar situation to that of Qubes OS, and so I suspect features developed for one can help the other as well.

[ninavizz]

I wonder if we can use features developed for Flatpak integration here.

I don't know—but tbh, I feel the whole team needs to focus on user needs, first. Then, develop concrete problem statements. Then, seek to solve for specific problems, with identified related problems, with solutions that center around addressing user needs and project sustainability, more than embracing one kind of tech over another (which isn't to say that I see anyone intentionally doing the opposite—I just think the opposite is very easy to fall into).

Right now I feel the central "problem" this issue was created to address, has been lost. Where would the value of Flatpak integration be, and to whom? What features, also?

"Features" is a very scary word to many in UX—because in a way it throws a flag that implementation details are being considered, before a concrete user need, problem, and solution opportunity, are identified. I mean, yes—y'all are developers, Qubes is a touch complicated, so implementation things must be considered to inform solution opportunities... but the tail can also get up to chase the dog, if we're not careful. I want to be mindful to not let that happen.

That said, I'm happy to continue this discussion if there is a concrete user need/shortcoming identified, that could be solved by switching to a new DE. Otherwise, while I do ultimately desire moving away from XFCE, it feels like we're too early in learning about Qubes user needs, to begin that journey. And, we have sooo much other stuff we have to focus attentions on. If that makes sense.

Some Amish do object to zippers but not because they are "radical new technology;". In fact there are various of the Amish who do use zippers. For those that don't, it is, I think, because they prefer to make the things they use, and they object to things that may be used to lead to separation in the community. Old Order Amish prefer hooks and eyes to buttons too, for the same reasons.

I've read many reasons for the general aversion to Zippers. Much of the Amish's eschewing of tech, I've heard best summarized as a desire to become closer to God by not being distracted with complicated things that take our minds from the most basic of agrarian, family, church, and community-supportive tasks. Same, with the preference for "plain" appearances. When it takes hours to hew a simple beam for a big giant barn, that is more likely to bring a person closer to God and to appreciate the simple fruits of the Earth, than ordering a milled/treated beam that grew in Brazil, was milled in Colombia, and purchased at Home Depot. Assuming of course, that you don't hew that beam with speed-metal blaring in the background, or with a blade you sharpened on a bench grinder, etc.

Zippers, specifically, came about after the OG German Amish came to America—and the rejection of technology in practice, was more about a rejection of secular "English" (mainstream American) culture from their time of immigration to the US. That focus on community inter-dependence and desire to isolate from secular America is why they became such a "maker" culture, making almost everything that is used within the community. But then economic factors of the Capitalist hellhole that surrounded them made it impossible for the Amish to isolate completely (namely, corporate agriculture ruining Amish dairy/produce/meat sales outside their own communities), so they had to start sending teens out to work at local neighboring businesses, young adult men to do construction outside the communities, etc.

Yeah, there's lots of Amish communities of every flavor—and really, I think it all comes down to what each's bishop specifically wants for his own community, for which he serves as an oppressive patriarchal dictator. I also used to think it was an Old Order vs newer rule wrt the eye-hook vs button, but it seems really random (or more regional?). Also, as a sewist... for buttons to not become a problem, the amount of labor involved in sewing the button-hole is very non-trivial. Eyes and hooks are waaaay simpler to put in.

Is Andrew shaking his head and crying yet, from how off-topic this is?

[DemiMarie]

Right now I feel the central "problem" this issue was created to address, has been lost. Where would the value of Flatpak integration be, and to whom? What features, also?

Sorry, that was poorly phrased. What I meant is that if GNOME had already written code for Flatpak integration, we might be able to use some of it.

[demeralde]

I'd even argue using the Pop!_OS shell instead of regular GNOME. It's the best of both GNOME and i3. If someone implements this flawlessly with Qubes, I think I'd be sold.

[ninavizz]

Being able to integrate the DMenu stuff into Qubes w/o requiring the full tiling (primary) switchover to i3 would be a giant win for users, I suspect. LOTS of requests to bring D3 functionality into the new app menu stuff, so i3 users don't have to pick one or the other.

[v6ak]

Dmenu is cool (I use i3 BTW) and I love it, but I am not sure if it is what Gnome/Xfce/KDE users usually expect:

1. It doesn't show any icons. This fits well to i3, but can look quite strange in Gnome/Xfce/KDE.
2. It cannot be controlled by mouse or touch, just with keyboard.
3. When you open it and forget, it has some unwanted side effects. It seems to prevent screen lock and IIRC also prevents other windows from being used. User might not notice that they need to press Escape.

Technically, using dmenu in Gnome/Xfce/KDE can be matter of just one keybinding, as it is in i3. It's really easy. But I am not convinced it is a wise default in non-geeky desktop environment.

[v6ak]

That said, it is completely OK to document how to use the i3-dmenu-desktop with other Desktop Environments.

[ninavizz]

On this topic, from the AppMenu survey:

"1) Make Qubes OS more usable for people with KDE-based templates, dolphin and Qt filesave/fileopen dialogs. 2) Each KDE-based qube should have shortcut in tray menu - open dolphin (or filenamanger script, the same as currently done with terminal). 3) Each qube should have an optional submenu with custom links, e.g. this qubes is for browser, this one dolphin (e,g. samba via vpn), this one qbittorrent and etc. 4) Make Qubes OS better for people with 30+ VMs. Storage space is cheap, so why not use plenty of them. But it causes troubles currently, start menu in XFCE opens 3 seconds for the first time. It has no search too (XFCE is not great and nor comfortable), so scrolling and searching VM manually is also a pain. So, I prefer not use start menu at all in XFCE, better to open dom0 terminal and run qvm-run vm konsole & from history. Yes, current XFCE menu is that bad if you have many VMs.

[ninavizz]

@v6ak Thank you for the excellent feedback points on the DMenu stuff! Users across DEs really want more keyboard-only control of their OS... so while, yes, it was only really i3 and super-Linux folks requesting DMenu outright, it is a realm of inquiry I like having open to explore some more (both with users, and technically).

[v6ak]

Hmm, when thinking about dmenu-like functionality rather than specifically about dmenu:

Xfce has some similar functionality (Alt+F3, xfce4-appfinder), but it has two drawbacks. First, users might miss it. Second, it does not fit that good to Qubes OS. In Qubes OS, you might often have some apps used in 30+ VMs. In such case, I usually want to type part of the app name and part of the VM name (e.g., ”ban fire“ for ”banking: Firefox“), which doesn't work well with Xfce App finder. However, it can be easy to use some other app finder instead, as it is just an application bound to the keyboard shortcut. Advanced users can use i3-dmenu-desktop instead, as long as they don't mind the UI mismatch. But there are probably multiple such apps, one will hopefully fit well.

Gnome has a built-in search which is IMHO pretty visible. I am not sure it it fits well to Qubes OS, but I am mildly convinced it is OK. Unlike Xfce, it would be probably considerably harder to replace the search.

KDE – IIRC, it has some similar functionality, but my last attempt to use KDE is quite old and I don't remember it enough.

[SvenSemmler]

dmenu (i3), appfinder (xfce), spotlight (mac) ...

... it's all the same principle: hotkey, type a few letters, return

Over time you build up muscle memory, especially with the 10-20 things you need all the time every day. Pretty soon you are launching apps faster then the time it would take to move your hand from the keyboard to the mouse.

That's what's so powerful / addictive about this model. It's not good for discovery, but if you already know what you want nothing can beat it in terms of speed and minimal friction

[ninavizz]

Yup! All of this, we need to make work with Qubes. Not rocket science, just mental models and details to finesse. And, developer time to make fit well.

Also: Having now finished the first pass of synthesis on the appmenu survey (it'll take about 3 passes until I'm "done" with a publishable article), I can assert a strong interest in Gnome from just the open form comments on that. There were also some open form comments about KDE (and many complaining about its perceived bloat on system resources, heh), but all of that will be quantified in the article that ends up getting published. Just FYI.

[unman]

[quote]

KDE ??? IIRC, it has some similar functionality, but my last attempt to use KDE is quite old and I don't remember it enough.

[/quote]

Yes, KDE has built in search both in the menu and as separate drop down.

[DemiMarie]

There is a major problem with GNOME’s Wayland compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/1836. In short, GNOME does not support server-side decorations on Wayland, at all. It expects each client to draw their own. That means we need to either draw these decorations ourselves in the GUI daemon, or convince Mutter’s developers to change their mind.

[DemiMarie]

Update: Mutter will never support server-side decorations, which means that the GUI daemon will need to draw its own decorations itself. GTK is the only way to draw decorations that are consistent with the rest of the desktop environment, but GTK is not well-suited for this task, as it is not friendly to direct interaction with Wayland.

@ninavizz: how important is it that the window decorations be consistent with those provided by GNOME? Ensuring this will likely add substantial complexity and may cause problems with accessibility support.

[ninavizz]

Responded to @DemiMarie in an outside chat. TL;DR, "GNOME-y" or "KDE-y" etc are less important, than supporting colored frames in Qubes as elegantly, usably, and otherwise neutrally as possible. #6414 shows a proposal that does not have to be married to XFCE, but in an ideal universe is how I'd like windows to look in Qubes. :)

My preference for GNOME overall, is for how its family of components all work across UI functions. Can elaborate later, if desired.

[DemiMarie]

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1014 is going to be another difficulty. The recommended workaround appears to be a shell extension in JavaScript, but that is only an option for icons in the GUI qube.

[DemiMarie]

Not sure if that is helpful, but there is an alternative solution: use client-side decorations. The actual VM windows are technically owned by gui-daemon process in dom0 (or other GUI VM in the future), so we have full control what is does. The issue here is it being plain C application, accessing X11 messages directly - which may be highly non-trivial to combine with GTK3 code for drawing decorations. But maybe I'm wrong here? Note this part of qubes is very fragile, as there are a lot of different applications, each with own set of quirks - causing issues like like #5424 or #3982.

From a purely technical perspective, client-side decorations are probably the best option. They are fail-secure, as errors will crash the GUI daemon. They are also portable to all Wayland compositors and X window managers, and have the same look and feel on all of these platforms. In light of #6414, this is actually desirable! Desktop environment theming code is very complex and I would prefer to not rely on it for security, whereas client-side decorations should Just Work.

That said, good client-side decorations are a LOT of work, especially since accessibility is a requirement. Having the GUI daemon draw them would add a significant amount of complexity. That is undesirable in one of the most security-critical parts of the system.

[DemiMarie]

I finally figured out a solution last night:

Instead of launching the GUI daemon normally, the GUI daemon is launched by a GNOME shell extension. The extension uses the MetaWaylandClient API to allow it to identify the windows owned by the daemon. This is race-free by design, and is designed to be secure against spoofing by untrusted sandboxed (ex: Flatpak) clients, so it is more than sufficient for our purposes.

Before the daemon draws a window, it asks the extension to draw the window’s border. The daemon only draws the window if the extension draws the border successfully. Otherwise, the daemon considers this to be an error condition, preventing a window from being drawn without a suitable border. If the extension is not loaded, the GUI daemon will never be launched, which is again a safe failure mode.

[jonkri]

It's great to see that the Bountysource bounty has reached $6,400. Hopefully we can see some more progress towards this soon!

Merry Christmas, all! :christmas_tree:

[code3z]

Hi, I already got this working a little while ago: https://gist.github.com/code3z/244ea17d306f11fdf1127c8d4ce5296c There are a few bugs, like with the microphone and HDMI, but I think those have to do with the OS and my hardware, not GNOME. I have been using GNOME with a second display for a few months now. I posted the code and instructions for window decorations but it is a bit hacky.

[ghost]

It's great to see that the Bountysource bounty has reached $6,400. Hopefully we can see some more progress towards this soon!

Re Bountysource, please be aware of this:

abebeos/bountysource#1

[anonaddict]

It's great to see that the Bountysource bounty has reached $6,400. Hopefully we can see some more progress towards this soon!

Re Bountysource, please be aware of this:

abebeos/bountysource#1

After looking a bit further into it it does seem really shady and I've found several people saying similar things

https://github.com/mumble-voip/mumble/discussions/5403

https://github.com/bountysource/core/issues/1539

https://blog.elementary.io/goodbye-bountysource-hello-github-sponsors/

https://github.com/bountysource/core/issues/1560

https://en.wikipedia.org/wiki/Bountysource

[ghost]

@ maintainers: why would you hide my comment ("This comment has been minimized."), whilst keeping others which mention bounty-amounts open? My warning addresses each and every person which has contributed to the bounty. You should respect those people.

@anonaddict , yes, it's a drama. After I started analyzing bountysource here https://github.com/abebeos/bountysource, they send me the cashout next day (after 17 days).

I'll keep the repository for now, trying to fix bountysource, but most possibly what happened is that they do not have enough liquidity, due to embezzlement of funds.

[andrewdavidwong]

why would you hide my comment ("This comment has been minimized.")

Simply because it's off-topic relative the technical matter of adding support for GNOME in dom0 or the GUI domain. Hiding your comment doesn't reflect a judgment about the truth of what you wrote, only its relevance. The issue tracker is a technical tool intended to support our developers in their daily work, and the more unrelated comments they have to sort through, the less useful it becomes for them.

whilst keeping others which mention bounty-amounts open?

We tolerate other comments about bounties because we understand the practical necessity that funding is required for most work to get done, and those comments are typically brief and easy to skim. Your comment doesn't just mention a bounty amount. It's one step further removed in discussing the third-party bounty platform that someone else has chosen to use to place the bounty. I chose to hide (rather than delete) your comment as a compromise between allowing others to see your concerns without it becoming a distraction. Arguably, this has proven too generous, however, as someone then replied to you, posting a comment about investigations of this third-party platform, and you further replied to them, taking the discussion further and further off-topic.

My warning addresses each and every person which has contributed to the bounty. You should respect those people.

There's an appropriate time and place for everything. Even though your warning might be well-intended, this is simply not the right place for it. (Consider how someone passing out flyers might not be welcome inside every place of business. It has nothing to do with the contents of the flyers, which could be the most true and helpful information in the world.) You should respect that this is a technical issue tracker designed to be a tool to support the devs and with its own set of guidelines to that end, not a platform for you (or anyone else) to spread your message to the Qubes community.

If you wish to discuss this matter further, please start a forum or mailing list thread.

[marmarek]

After several considerations, sadly it seems like official support for GNOME is not a viable in Qubes OS. There are several technical details (you can find them in the discussion above), but the summary is that GNOME is tightly integrated with their vision of the desktop which is incompatible with Qubes OS. Some of it can be tweaked with extensions (but the API there changes so maintaining it will be substantial amount of work), some requires patching at source code level (which is even more work to maintain). And some (like server-side decorations) won't work under Wayland at all (and the native X11 support is going away).

If GNOME approach will change, we may reconsider this decision. Until then, there won't be official support for GNOME. If somebody is willing to maintain set of packages and extensions that make GNOME functional on Qubes OS, we have a contrib repository that could be used for that.