Wayland Protocols 1.38 Brings System Bell, FIFO & Commit Timing Protocols

[PennRobotics]

I have noticed that this forum is quite divided over many things, and one of them is whether GNOME is good/bad.
From my point of view, I like to support diversity, meaning that every user chooses what he likes most. I don't have any particular stance about GNOME.

So Weasel (or, someone else), could you please explain to me what are the worst of GNOME's transgressions. I would like to evaluate those. Besides explanations, I also accept links to evidence or links to articles that explain the issues.

• GNOME bugs attract PRs from aggressive devs, GNOME occasionally responds to legitimate issues with, "well, that's your opinion; locked"
  • Example 1: https://felipec.wordpress.com/2024/0...me-developers/ although all parties involved could have been a whole lot cooler and similarly solution-oriented.
  • Example 2: https://discourse.gnome.org/t/constr...riticism/18338 (currently down for me) originating from a separate discussion
• Nautilus will search a whole file tree when typing rather than selecting the matching file in the current directory; quite a few people miss this functionality
• Round corners, which seek to humanize the UI, which is why all major newspapers as beacons of humanity are printed on paper with rounded corners /s; quite a few people miss the non-rounded functionality
• Dock and top bar are not very customizable without extensions
• Extensions break and/or introduce bugs all the damn time
• GIMP doesn't handle 10-bit monitors well (this might be fixed, I stopped using GIMP on that system) which is why the majority of my color swatch selections are/were bright magenta and the background becomes translucent and strangely colored in weird places, such as toolbar buttons.
• The GNOME Gitlab itself is configured poorly. If you click a few issues and search for some term, your IP gets flagged (due to multiple async data requests in a short interval) and then subsequent browsing gets 429'd for 15 or 30 or 60 minutes (I'm not actually sure, but far more than 5 and long enough to dissuade a curious developer from browsing or contributing)
• Personally, I dislike the very first screen, where you have your "desktop" (which you can't put anything on, just like a real-life desk /s) sunk in on some muted background and have to push escape to get everything to show up as-normal. This is, of course, not an option unless you use an extension, which will then sometimes cause seemingly unrelated but major usability problems (alt+tab breaking, hanging, suspend not working properly, Control Center throwing errors)
• GNOME devs work on minor features (hey thanks for accent colors /s) while seemingly significant bugs exist like scrolling on a MX3 Master breaking the file manager because of a bug in Gtk (has been fixed)
• Building gtk is a pain in the ass for an embedded systems developer who doesn't do gtk builds constantly. That's at least my experience. It also forces you to set up Flatpak and download tons of devel files, which is irritating if your computer intentionally didn't have Flatpak set up. Alternatively, you can install Docker and discover a new Docker-related issue seemingly every month; this is irritiating if your computer intentionally didn't have Docker set up.
• GNOME Builder didn't respect my company proxy variables, which are set correctly for everything else I do.
• GNOME is responsible for Wayland. Nearly every time WINE crashes on my computer, the log states there was a bug in libmutter. If I submit an issue to WINE, they direct me to mutter. If I submit an issue to mutter (after creating an account and 2FA and jumping through a half-dozen hoops, one which might be getting "Retry later" for an hour) the response ranges between "not our problem", "not an issue", and "already fixed, wait for it to hit the repo"
• I've found multiple ways to get gnome-control-center to crash (configuring a printer too fast and continuing to use the Printer controls, setting up a stylus that hasn't been added to the wacom repo yet, configuring color profiles, mixing Bluetooth commands from the CLI while adjusting Bluetooth settings in the window)
• You don't have to travel far to find hypocrisy in maintainer messaging. "It's mostly volunteers." Quite a few of these volunteers are employed by Red Hat or payrolled FOSS companies. "Roll up your sleeves and contribute." Sure. Suppose I submit a PR, "sets all UI corner radii to 0.01 and removes extra padding when a hidden dconf setting is active." This would almost certainly be met with rejection and ridicule. "You're welcome to use any different DE." If I buy a ThinkPad for my house with Linux preinstalled, it's going to arrive with GNOME as the default. The same if I choose Linux for my workplace computer, and they're far less likely to allow changing as it's a maintenance burden.

So, do I accept the defaults? "{GNOME dev}Here's the Unicode entry shortcut, it's what I use, you can't configure that key combo any other way, because I don't like that and only my opinion matters," or perhaps, "Please decide between your computer crashing every week because of 'Extensions', some which should be merged as they're simply popular... or the default desktop/top bar/dock/workspaces/terminal, which are quite dislikable for both aesthetic and usability reasons."

In fact, it's curious that the majority of my problems seem to stem from a GNOME project (with nearly the rest coming from Firefox and AMD). Either GNOME is massive and that attracts a ton of bugs as a normal part of development, or they just have a way of writing buggy and opinionated software, and I'm more critical of the bugs because their opinions are often wrong.

[Bouleau]

Yeah, they're the best examples of how not to be as a developer and offer great insight into what to avoid.

It is never funny to be the one fighting complexity but it is still one of the most important task if you are creating something that will be around for decades to come.

[bearoso]

Thank you for the explanation.
However, I still don't quite get it.

I don't get it either. Eventually I just decided to use AMD for Linux machines. No one really knows what was going on because the driver is closed source. I also thought about that discontinuity: why could they have new WDDM support on Windows for day 1 when the features required were so similar and it was supposed to be a unified driver? They probably just didn't care. CUDA is a money-maker but Linux graphics users are a scant minority.

[bearoso]

AFAIK, before the vendor-specific surface buffer transfer protocols were put in place, nvidia refused to cooperate and attempted to nuke Wayland. Then they changed their mind, but their "concession" was to add their own, incompatible buffer-transfer.

Someone with more knowledge of the actual events could perhaps confirm this story, as I'm not 100% sure.

Back then, their Linux graphics support was really restrictive. It could basically run one OpenGL application at a time. If you tried to run two it would stutter like mad because the synchronization was probably heavily lock-contended. Composited window managers didn't work well with it. The EGLStreams thing was an probably an attempt to avoid fixing those problems, because fixing it cost more money than working around it. They needed to keep Linux+NVIDIA because of CUDA, but what would people say if they removed the graphics part? They had to do something at least acceptable, and they've been coaxed to spend more on the problem than they wanted to.

[Weasel]

Gnome developers are still great developers with useful insight

Yeah, they're the best examples of how not to be as a developer and offer great insight into what to avoid.

[bearoso]

nuke wayland? i think its better to say that nvidia wanted to use different approach for wayland and the rest refuse it. well maybe i understood wrong

Nvidia wanted EGLStreams to make the compositor more "pure", in a sense. The idea was that clients hand off buffers and they become opaque and invalidated on the client side. This seems to fit with their swap queue approach. I'm sure it meant the hardware was different in some fashion and that GBM's flexibility would require similar workarounds on their end to those the compositors had to make for EGLStreams.

You can kind of see this with how Vulkan image layouts are completely unneeded on nvidia. I think this capability was to facilitate a unique control flow in the graphics components.

[loganj]

Maybe that's a thing that could've used some friendly consultation from GPU vendors then. Unfortunately the likes of Nvidia pretty much tried to nuke Wayland in the beginning instead of embracing it, so people with less know-how had to make do alone.

nuke wayland? i think its better to say that nvidia wanted to use different approach for wayland and the rest refuse it. well maybe i understood wrong

[curfew]

But, Wayland designers glossed over the buffer transfer protocol in their original design of Wayland, so each GPU manufacturer created their own buffer transfer protocol. And, each one of those was bad.

So now, each GPU manufacturer is "bloating" Wayland compositors with their own mutually incompatible protocols for all functionality that Wayland initially omitted.

Maybe that's a thing that could've used some friendly consultation from GPU vendors then. Unfortunately the likes of Nvidia pretty much tried to nuke Wayland in the beginning instead of embracing it, so people with less know-how had to make do alone.

[reba]

so I was pushed to try cosmic, and I have a lot to say about it's potential, but it clearly shows that they didn't come from the x11 world, there's just many things that would be a big pill to swallow for me to cutover any time soon. that being said, it's mostly usable today, which is nice that there's a viable stacking compositor besides kde/gnome for wayland.

Let me drop a link to labwc

https://github.com/labwc/labwc

https://labwc.github.io/

Labwc is a wlroots-based window-stacking compositor for wayland, inspired by openbox.

It is light-weight and independent with a focus on simply stacking windows well and rendering some window decorations. It takes a no-bling/frills approach and says no to features such as animations. It relies on clients for panels, screenshots, wallpapers and so on to create a full desktop environment.

Labwc tries to stay in keeping with wlroots and sway in terms of general approach and coding style.

Labwc has no reliance on any particular Desktop Environment, Desktop Shell or session. Nor does it depend on any UI toolkits such as Qt or GTK.

[curfew]

It's definitely much easier when all you have to care about is Mesa.

It's also easier for proprietary drivers to fix their own performance issues inside those drivers and not try to bloat random window managers and whatnots with their crap.