Hacker News Reader

Agreed. The blog post's author ignores that the GNOME project isn't willing to support basic interoperability with other software, and instead wants to make a GNOME-exclusive ecosystem. The GNOME project's refusal to support XDG-Decoration (https://gitlab.gnome.org/GNOME/mutter/-/issues/217) means that even if you're writing something like a game and not using any of the system's UI, you either have to add GTK as a dependency to get the "correct looking" titlebars or spend useful development time writing shitty, non-native looking window decorations just for GNOME users. It's not just "if you disagree with our UI decisions, don't use our DE", it's "we want the Linux desktop platform to match our uncompromised vision and we will make it as annoying as possible for GNOME users to run your software if you disagree".

> The blog post's author ignores that the GNOME project isn't willing to support basic interoperability with other software, and instead wants to make a GNOME-exclusive ecosystem.

Does it, though?

"My way or the highway" fits very well in this context. "My way or the highway" can also be interpreted as "we don't give a single shit about other software and other people, and we don't care about interoperating with them".

Basically GNOME is living in and pushing a world where there's only GNOME.

And this is where things get tricky and I feel for the supposed "haters": so now you (GNOME) are a big project and you're pushing your own incompatible and non-interoperable stuff. Some projects will adhere, some won't, for any reason.

So now if I'm using anything not GNOME my desktop experience is broken, because software that assume GNOME is running won't work well (if at all) in other environments.

It just wasn't this bad before GNOME3 and this mentality shift.

>Basically GNOME is living in and pushing a world where there's only GNOME.

No, that's false. I can't see why you'd even think that. GNOME wouldn't be using Wayland at all if that were true. GNOME uses standards where they make sense, this one optional non-standard part of Wayland just happens to not make any sense for GNOME. They don't have any issue with the rest of Wayland.

It’s not false. Not supporting decorations actively causes problems for non-GNOME software.

No. How would that even make sense? If you have no GNOME-related software on your computer at all then it won't affect it.

>you either have to add GTK as a dependency to get the "correct looking" titlebars or spend useful development time writing shitty, non-native looking window decorations just for GNOME users

That's a false dilemma. You don't have to do either of those. The alternate solution is mentioned in that issue: use libdecor. I'll also note, if you refuse to use any of the system's UI and you insist on implement everything yourself directly on libwayland then that's an entirely self-inflicted problem that you created. Libwayland is fairly low-level, it isn't a game development API. Besides window decorations, you'll have lots of other deficiencies and things you have to spend development time on. That's what you volunteered for, GNOME can't help you with that.

I mean, yeah, you don't need the whole GTK library for titlebars, but you still need to drag libdecor along to support a subgroup (Wayland users) of a subgroup (Gnome users).

Its pretty annoying to add another moving piece to the machinery just to do that.

That's the way it is with any optional X11 or Wayland extension. Either you implement the extension yourself, or you use a library to implement it for you. Typically the code to do this is put in a toolkit, but you decided to write your own toolkit so you get to deal with the annoyance. Nothing's changed in this regard. Actually, most optional things in Linux are like this and it's been this way since shared libraries were implemented. If you find the idea of this so off-putting, maybe you should be using a pre-made toolkit instead of writing your own?

Great feedback, I'm just gonna throw a "gtk-layer-shell" on top of the burning pile.

I just don't care though, I've resisted the GNOME-ire until recently (hoping it was "just" drama and would blow over or be fixed by technical decisions in the future) but now, I have given up on the idea that GNOME apps are going to continue to "seemlessly" co-exist in non-GNOME environments, like in the past. Fine.

Fortunately, between various Wayland tiling WMs, KDE, Cosmic on the way, there are other options that don't require GNOME, or even GTK+. Good riddance.

I too hate the way they deal with CSD and I'd wish they'd change their opinions, but the project is theirs to manage and I can only accept that if I don't like it I can just use KWin. For those wishing GNOME stuck more to its origins, there's always Cinnamon.

As for the API stuff: why does the display server need to deal with power management? That sounds like something the power management API should do. IMO, the display server should just display things, not manage power states or login states. Wayland draws the screensaver, but the session manager controls the actual session.

Still, there is an open MR to accept this API (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/111) that needs to be rebased and needs a bug resolved. The solution falls perfectly in line with the GNOME way of doing things as well (forwarding the Wayland API to DBus so the DBus interface can do its thing), the only problem is that nobody is interested enough to do the hard work.

DBus is an excellent method to communicate anything that doesn't involve exchanging buffers. Many members of the Wayland project are trying to prevent going down the same path X11 went down, sucking up more and more features and API surface and becoming a huge, unstable, buggy mess because of its sheer code size.

As for your mouse cursor issue, Wayland's cursor_theme seems to be supported by at least. I can't find cursor_theme in the Wayland spec itself (there is a merge request at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... but I don't see much activity) so until that gets stabilized you can choose between using DBus or a bespoke, DE-specific API, pick a compositor that takes away cursor control from the application entirely, or switch back to X11.

> Many members of the Wayland project are trying to prevent going down the same path X11 went down, sucking up more and more features and API surface and becoming a huge, unstable, buggy mess because of its sheer code size.

I would argue that if you sum the code of all the Wayland compositors existing today + all the dependencies required for making them work as a proper desktop - dbus, wlroots, ... you likely have much more code (and thus much more bugs overall) than you had for X11.

xorg git repo is 400kloc of C, I've seen projects which were on the order of magnitude of 40 million lines of code and still were able to be managed, so to me "sheer code size" sounds a bit weird. Hell, the main project I work on, https://ossia.io and on which I do the huge majority of the swdev work alone is nearing 500kloc and it does not feel like a burden.

That's not a good comparison. To get a full picture, you have to compare the X server, all the Xorg drivers, the X client libraries, the X utilities, all the different X window managers and compositors, all the code from alternate X server implementations, etc. X11 desktops are all using dbus too so that one counts for both. All together added up it's significantly more code than Wayland, and that's even considering that the major Wayland compositors try to share as much as possible between the X and Wayland implementations. That is, Mutter and KWin didn't use wlroots. Wayland and X11 are just pluggable backends for them. Go and look there yourself if you want to make your own direct comparison. The Wayland backends are pretty small and they talk to the kernel directly, whereas the X backends have to go through all of that extra code just to talk a complicated protocol to the X server to accomplish the same task.

This is different situation for older non-compositing window managers that still use the old X11 drawing primitives. Compositors do all their drawing themselves using direct rendering to the GPU so are able to just swap out the backend without much trouble. That shift was happening in X11 in the years prior to Wayland and it's one of the reasons Wayland is even able to work.

One problem with dbus is that some compositors (for example sway) have a design goal of working in environments where dbus isn't available. And even if that weren't the case it means applications need to deal with multiple asynchronous protocols, which isn't that big of a deal if you are already depending on a big toolkit like gtk, but for a lightweight application that is working directly with wayland (or, say a game that draws everything itself and doesn't use a widget toolkit), it adds a lot of complexity.

Applications shouldn't use libwayland directly unless you're planning to implement your own toolkit and event loop and threading abstraction yourself. It's certainly a take to do things in the most complex way and then complain that you have to implement a lot of complexity. Off the top of my head, here are things that won't work that way unless you implement them yourself:

- Networking. The socket(s) will block your program loop.

- Audio. Has to be done on a separate thread with strict timing.

- Background loading. Get ready for your program to hang when loading a large file.

- Talking to any system services. Every common desktop uses dbus now. Really. Using sway on an embedded system without dbus is a niche.

- Power saving modes. Without an event loop you always have to use sleep to poll yourself manually, and that's wasteful.

- Simulations, physics, or anything else that requires a constant tick rate. These are dependent on running the rendering in another thread.

- Accurate timers. Any issues with any of the above will block a timer from firing.

There are probably a lot more too. What seems "lightweight" first can turn out actually not be lightweight at all.

And how should such an environment signal power management requests reliably then, without the de facto linux way?

Sorry, I mean inhibit-idle support from the GTK side, not from the Mutter side. As a client.

The D-Bus focus is understandable if one recalls some of the early discussions on Wayland. Namely that all sorts of stuff were to be relegated to D-Bus interfaces instead of protocol extensions.

Essentially, GNOME project is going Wayland purist way.

I am not aware. I was on NVIDIA for a long time, so Wayland was a thing that I looked at from a great distance.

However, I can't recall that point ever really coming up specifically. Deciding what should be a standard Wayland protocol has a committee today though. And I understand that an optional protocol existing does not imply that all Wayland clients and servers must implement them, but things like idle-inhibit were added because it addresses a specific problem, and I think it's a real shame that the most popular toolkit on Linux will probably not get support for it.

I'm not trying to slander GNOME developers here, and they have no incentive to care about people's opinions who have nothing to do with them, but if they care a lot about their reputation as being a bully in the ecosystem, well, this is exactly the kind of thing that leads to this problem.

That "reputation" is complete nonsense. Outside of HN (and a few other places with low-quality moderation) I don't see anyone trying to push that "reputation" as a narrative. GNOME has no other option but to dismiss and ignore those claims. I mean it's literally "you're bullying me because you don't do what I'm demanding you to do right when I want you to do it."

The reputation is a real thing and it's why the only people who are choosing to use GTK for new projects are people who are already pretty deep into the gnome ecosystem (they've probably been to at least on gnome conference).

You can see this kind of effect by looking at toolkit preferences in things like the stack overflow surveys.

I was curious so I looked at the most recent stack overflow surveys that mention GTK. They actually say you're wrong.

https://survey.stackoverflow.co/2022/#section-most-popular-t...

https://survey.stackoverflow.co/2022/#section-most-loved-dre...

GTK has lower usage than Qt and Electron, but it's actually few percent higher on the "most loved" category than Qt and Electron. However all of them are below 50% loved. The percent GTK is above them is probably not enough to be important. And that's exactly what I'd expect: all these desktop toolkits have issues and are disliked. Electron and Qt are cross-platform so of course they would have higher usage than GTK, which has only ever really been popular on Linux. And none of it matters anyway. .NET wins it all by a large margin due to the popularity of Windows and the only other big GUI frameworks on there are Flutter and React Native. I'm honestly surprised GTK is even on the list at all, it wasn't there in previous years. I expected the list to be totally dominated by web frameworks and Python frameworks like it was before.

This is kind of along the lines of what I've been trying to communicate to you. Complaining about these minor issues and playing the blame game between open source projects is pointless. Microsoft, Facebook and Google are the big boys in town, that's not gonna change by GNOME fixing some random low-priority bug.

No, this particular "reputation" you're referring to is a lie and a fabrication based on nothing, in order to push a narrative. I mean you literally just walked it back right now, in literally the same sentence. The people choosing GTK are choosing to do that, they're not being bullied by anybody. I don't think anyone is developing anything for the express purpose of trying to "win" a stack overflow survey.

>the people choosing GTK are choosing to do that,

They are, presumably, not the people that Gnome are bullying. But I think we're past the point where you can I can have a reasonable conversation.

We could never have a fruitful conversation if all you were trying to do was trash talk some people. I won't engage you there. Once you abandon the idea that you need to tear other people down to make your point then you'll find our conversation will improve instantly.

>This is all assuming you want to use DBus. Why? Wayland is already the thing that you speak to talk to the display server. Why use another protocol for basic functions like this?

You have this completely backwards. Dbus was already standard on nearly every X11 desktop and was spoken by a lot of X11 window managers, before Wayland even existed. It was adopted during the X11 days because X11 is a poor IPC for anything outside of window management. It's notably bad at syncing settings where you commonly have an external process storing a settings database that sends notifications to interested applications. X11 is a poor fit for that, but dbus is great at handling that case with its signaling mechanism. Mouse cursor size being a good example of that type of setting.

>If DBus is so great, why do we even need the Wayland protocols in the first place?

Because they're two different protocols with different goals. Dbus is a general-purpose IPC that can be used for a lot of desktop tasks, like syncing settings. It's designed for many-to-many communication between every program on the system. Wayland is designed mainly for high performance between only one application (the window server) and its clients.

>Dbus is not great.

Dbus is the worst option except for all the others. I've seen a lot of dbus hate over the years but still no one has ever been able to propose a replacement. No, putting everything into Wayland protocols is not a suitable replacement.

I'm not sure if there's any point in arguing this but I am not suggesting the Linux ecosystem should just drop DBus. I can kind of see why it may read like I'm suggesting that, but it wasn't really my intent. Instead, I'm actually saying something much simpler; I think that not all users of Wayland will want DBus, and in those cases, the Wayland protocols is a very reasonable place to put functionality related to the display server. I understand that in the view of some folks, certain things do or do not belong in the Wayland protocol. However, I think that's moot. It's mostly philosophical where Wayland begins and ends. The truth is, idle inhibition is adjacent to the compositor, and thus reasonable to support. To their credit, GNOME does the much more reasonable thing in the Mutter side by supporting the idle inhibit protocol as a proxy for the equivalent desktop portals interface. This is a win-win-win, as it's not terribly difficult to do, it allows GNOME to still keep things organized mostly the way they want, it supports clients that don't want to use DBus for this, etc. It seems the GTK maintainers would be willing to merge support in GTK too, but it's not currently happening. This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to, though for the latter I have no idea where to begin. (except maybe bountysource or something, but I am uncertain of the effectiveness of that model.)

Now for something like syncing the cursor size, that belongs in Wayland. Duh. The Wayland compositor handles displays, their scale factors, and the hardware cursor. It's just common sense.

Wayland as a protocol is probably not good enough to replace DBus, but it is significantly simpler and lacks some DBus pitfalls. I think for things that could reasonably be handled by the compositor, it should be.

(I have other concerns about DBus, too, especially now that desktop stuff is moving to systemd user services. Aren't systemd user instances per user and not per session? How can you deal with DBus in that context?)

>This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to

You might consider joining the IRC/Matrix channel and making an offer to one of the maintainers.

>Now for something like syncing the cursor size, that belongs in Wayland. Duh. The Wayland compositor handles displays, their scale factors, and the hardware cursor. It's just common sense.

No, unfortunately it doesn't and it isn't. You're describing something that isn't Wayland. I've seen upstream Wayland developers following the rule of "it should only be a Wayland protocol if it requires access to Wayland object ids" and idle-inhibit does follow that rule (you can inhibit on a window id). Anything to do with mouse settings doesn't follow that rule. There was a conscious decision to keep settings handling out of Wayland protocols because, among other reasons, Wayland is designed for a specific thing (windowing) and is bad at being a settings database. It doesn't really even have a way to identify hardware devices, those are all abstracted away under "outputs" and "seats" which don't actually need to correspond to any physical device.

>Aren't systemd user instances per user and not per session? How can you deal with DBus in that context?

You only have one session bus per user and it's the one used by systemd. I mean, you can start more buses but why would you need to when none of the services you want will be using that?

From your own link:

> I don't think this belongs in the wayland protocol, but I'm not strongly opposed to using it as a fallback if not portal implementation is available.

Seems like a PR would be acceptable given Matthias' comment.

That's only one part of the discussion. Now I don't want to throw undeserved shade, but I'm already running two MRs on top of upstream GTK to work around issues where "patches are welcome" and I haven't checked in a while, but I'm guessing they're no closer to merging than before (edit: wrong; one of them WAS merged, and the other I stopped running due to FTBFS, though it's still not merged.) I understand that bandwidth is limited, but saying "patches welcome" as a project that is notorious for throwing that out even when it's probably not going to be merged feels kind of scummy, because it basically enables doing one thing and saying another without need to justify or discuss it. It's obviously the GNOME developer's volitions if they don't want spend any cycles on it, but the message sent to the Wayland ecosystem is not great, and it's going to be a thing I think about when I hear "GNOME Project" for a very long time.

(And frankly, soliciting patches for an issue then having the contributor sit for over a year rebasing without any substantial feedback is just kind of shitty.)

Could you perhaps link to your MRs that you are just rebasing over and over again?

Not my MRs, just ones that I am applying locally.

That said, I will retract: the main ones I was interested in have actually closed. I did not notice that !3898 was closed because it got superseded, but I had been applying that one for a long time. I am interested in !4672, but it broke my build so I don't currently have it on. Dunno if that one will get merged. It's in the unfortunate place of being neither approved nor denied. I can't blame the GNOME developers too much here, since everyone is pretty much a volunteer, but it's definitely not a fun experience. I have some in flight PRs that are going nowhere to other projects including Sway right now.

For 4672, you could always bump it and/or take over the MR yourself.