4 ms·

I would be happy if they stop opposing server side decorations in Wayland. Weston and Mutter are probably going to wind up being basically the only two Wayland

by jchw 4y ago

I would be happy if they stop opposing server side decorations in Wayland. Weston and Mutter are probably going to wind up being basically the only two Wayland WMs that don't support it, making GNOME an unfortunate and avoidable edge case. I think the CSD initiative is fine if it's a choice. However, I can't choose to not use GNOME on behalf of my users. Libdecor is a bad and C-centric solution to the problem. I know Mutter is designed in such a way that makes this hard; that was a pretty big misstep in my opinion. Likewise for other things that GNOME Project pushes. Here is a great example. Wayland has a protocol for inhibiting idle called inhibit-idle. GTK won't use it. Instead, they want you to use a DBus interface from the enormous XDG Desktop Portals API. They refuse to have any kind of discussion about it. End of story. https://gitlab.gnome.org/GNOME/gtk/-/issues/2202 https://gitlab.gnome.org/GNOME/gtk/-/issues/2202 This pattern repeats for even silly things. Like the size of the mouse cursor on HiDPI screens? No problem bro, just use this bespoke DBus API. 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? If DBus is so great, why do we even need the Wayland protocols in the first place? (Dbus is not great.)

tristan957 4y ago
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.
- jchw 4y ago
  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.)
  - tristan957 4y ago
    Could you perhaps link to your MRs that you are just rebasing over and over again?
    - jchw 4y ago
      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.
      - tristan957 4y ago
        For 4672, you could always bump it and/or take over the MR yourself.
p_l 4y ago
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.
- jchw 4y ago
  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.
  - QUrprUd1nCeicw 4y ago
    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."
    - traverseda 4y ago
      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.
jeroenhd 4y ago
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 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/-/issues/58 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.
- jchw 4y ago
  Sorry, I mean inhibit-idle support from the GTK side, not from the Mutter side. As a client.
- thayne 4y ago
  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.
wereallterrrist 4y ago
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.
ndiddy 4y ago
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 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".
- znpy 4y ago
  > 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.
  - QUrprUd1nCeicw 4y ago
    >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.
QUrprUd1nCeicw 4y ago
>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.
- jchw 4y ago
  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?)

by jchw 4y ago

tristan957 4y ago

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.

jchw 4y ago
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.)
- tristan957 4y ago
  Could you perhaps link to your MRs that you are just rebasing over and over again?
  - jchw 4y ago
    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.
    - tristan957 4y ago
      For 4672, you could always bump it and/or take over the MR yourself.

p_l 4y ago

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.

jchw 4y ago
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.
- QUrprUd1nCeicw 4y ago
  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."
  - traverseda 4y ago
    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.

jeroenhd 4y ago

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 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/-/issues/58 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.

jchw 4y ago
Sorry, I mean inhibit-idle support from the GTK side, not from the Mutter side. As a client.
thayne 4y ago
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.

wereallterrrist 4y ago

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.

ndiddy 4y ago

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 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".

znpy 4y ago
> 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.
- QUrprUd1nCeicw 4y ago
  >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.

QUrprUd1nCeicw 4y ago

>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.

jchw 4y ago
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?)