6 ms·

> KDE isn't too buggy, GNOME is a complete disaster. What did the author mean by this? Don't know much about Wayland other than it is window system, replacing

> KDE isn't too buggy, GNOME is a complete disaster. What did the author mean by this? Don't know much about Wayland other than it is window system, replacing x11. KDE Plasma wiki[1] says, "KDE Plasma 5 is the fifth and current generation of the graphical workspaces environment created by KDE....KDE Plasma 5 uses the X Window System and Wayland." [1] https://en.wikipedia.org/wiki/KDE_Plasma_5 https://en.wikipedia.org/wiki/KDE_Plasma_5

lights0123 3y ago
There is no de-facto Wayland software like there is the X.org server. Wayland is just a protocol—KDE and GNOME (through Mutter) both implement it. The author is saying that KDE did so better than GNOME.
djbusby 3y ago
Briefly: it's a big lift for all the different desktop environments (DE) to move from X11 to Wayland. Lots of moving parts; re-implementing and re-factoring is needed.
- londons_explore 3y ago
  The vast majority of users today run a hybrid of Wayland and XWayland... Getting the worst of both worlds, and extra bugs to go on top...
  - nolist_policy 3y ago
    That is not true though, XWayland is better maintained than native Xorg. It is here to stay for backwards compatibility. Disclaimer: I run ChromeOS and Wayland just works.
    - djbusby 3y ago
      Oh, I've got a Chromebook; didn't know it was all Wayland. I'm thinking that it "just works" there because G has more resources to patch all the needed features. More resources than KDE or Gnome or others have available.
      - NekkoDroid 3y ago
        I assume its mostly because how you said they can do it and the impact is really only limited to their system AND chromebooks are to my knowledge way more focused of a UX than what Wayland needs to be able to support so they can be even more opinionated about what they support and how
CuriousCosmic 3y ago
KDE and GNOME roll their own wayland libs for their compositor. These have varying levels of quality with their own unique quirks and bugs. The "gold standard" for wayland at the moment is wlroots which is what basically every other wayland compositor uses. PCSX2 apparently works perfectly fine on wlroots based compositors but has some quirks with KDE wayland and is nigh unusable with GNOME's super janky wayland implementation.
- abrouwers 3y ago
  Funny, I've used a wlroots environment recently (hyprland), and noticed tearing in animations that I don't have in gnome. So, I guess I'll take "janky" :-)
  - gkbrk 3y ago
    I thought tearing was not a thing on Wayland, and every frame was perfect.
    - abrouwers 3y ago
      Sorry, "tearing" isn't the correct word. I use the swipe gesture to "peak" at another workspace - if I have a video playing in that workspace, for example, it'll have artifacts in the playback while I'm mid-swipe. On gnome, the picture is perfect - I can swipe half-way, and the video is playing frame-perfect, as if the workspace was in focus.
DistractionRect 3y ago
Basically Wayland only supports a subset of what X11 could do. It's more scoped and does a good job with what it's supposed to do. That said, the rest of the functionality is now an exercise for desktop environments, and they can (and do) things differently.
- LtWorf 3y ago
  > does a good job with what it's supposed to do. And anything that people used to do on X11, they are told by zealots that they are wrong and aren't supposed to do that. For example: Not losing all the work every time your windows manager crashes remapping keys Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev) Global shortcuts tunnelling over ssh
  - Arnavion 3y ago
    >Not losing all the work every time your windows manager crashes https://news.ycombinator.com/item?id=37509703 https://news.ycombinator.com/item?id=37509703 >remapping keys >Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev) Up to the compositor. >Global shortcuts Also up to the compositor. Was added to xdp in https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.GlobalShortcuts.xml https://github.com/flatpak/xdg-desktop-portal/blob/main/data... so it's up to the compositor's xdp impl to provide it. It was created by a KDE dev so I assume KDE implements it at least. >tunnelling over ssh https://gitlab.freedesktop.org/mstoeckl/waypipe https://gitlab.freedesktop.org/mstoeckl/waypipe
    - LtWorf 3y ago
      > Up to the compositor. > Also up to the compositor. Exactly my point! Right there. Thanks.
      - erinnh 3y ago
        What’s your point? You didn’t make it. Before you said that your point was that people tell you you aren’t supposed to do those things. But you are able to remap your keys. Remapping keys has been possible in Wayland for quite a while in any compositor I used. (KDE, Gnome, Sway)
OmarAssadi 3y ago
As noted by other commenters, there are several compositors available for Wayland (essentially the bit that actually implements Wayland). Some are developed independently of any particular desktop environment--like wlroots, labwc, hikari, etc--but some are part of a larger project, such as mutter and kwin (GNOME and KDE, respectively). Most of the time you install some sort of GNOME/KDE + Wayland distro, you'll usually also end up with their compositors, and thus potential quirks specific to their implementations. GNOME's implementation in particular has historically caused a lot of drama relative to some of the others -- be it due to purely accidental, broken support for something, or sometimes intentional opposition to a particular concept that many applications rely/used to rely on, like server-side window decorations [1]. The accidental issues that come with fragmentation of the ecosystem and the intentional decisions by different compositors to not support particular extensions/whatever, like the aforementioned, can cause a fair bit of pain for developers of end-user programs. Users who may be totally unaware of the inherent differences between Wayland and X, who may not know that different compositors exist, who may not even know they are running Wayland, etc, inevitably run into strange issues, and then, understandably, file bug reports. This can get old quickly under normal circumstances. But I imagine it sucks even more when you're maintaining software that is relatively understaffed given its importance. Outside of PCSX2, mpv would be a good example: - It's incredibly popular software on its own, being probably the most popular open-source, cross-platform mediaplayer after VLC. - It's also embedded and used as a base for other applications on a wide variety of systems, ranging from other open-source players that try to integrate more tightly with a given platform--e.g., IINA (macOS), mpv.net (Windows), etc--to proprietary, commercial software, such as a variety of Android players and, importantly, Plex, which uses mpv as the default backend on at least tvOS/iOS/iPadOS. - It's software that needs to deal with pretty low-level graphics and audio stuff, so it's inherently a bit complex, and the available pool of potential contributors shrinks. - It tries to be as lightweight as possible and allow for easy embedding into other applications and porting to different systems, so it has several things working against it: -- It's mostly written in C, making it very easy to build and embed anywhere, but not only is C not the sexiest language in 2023 to many, it's also a hard language for someone without a good grasp to write safe, quality code, particularly for something like mpv. -- It doesn't try to enforce a particular rendering backend--e.g., OpenGL, DirectX, Vulkan, Metal, software, etc--nor a particular UI toolkit. Again, great for someone building on top of it. But it makes things like the change from server-side decorations to client-side significantly more annoying / potentially fundamentally incompatiblew ith the project goals. mpv sits in that perfect anti-goldilocks zone: It's important enough to be a problem if it were to disappear, yet unlike the Linux kernel, not quite important enough to have the funding and hoardes of patches despite the project complexity. It's also low-level enough to need to worry about every display server and platform on the planet, yet not low-level/general enough to have a say in the design decisions (e.g., Wayland membership, I believe, is pretty much limited to compositors and UI toolkits - like QT/GTK). All of that, and probably more, adds up to maintaining a surprisingly important, difficult project with relatively few developers but likely many millions of users, many of whom may not even know you exist; it's thankless yet important work. As a result, unsurprisingly, in addition to the infamous locale rant [2] (unrelated to Wayland), mpv used to have a pretty spicy wiki section entirely dedicated to GNOME's Wayland implementation: - https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d25681ce10cb6fa4c6759aaec063#user-content-I_use_GNOME_Wayland_and_I_have_xyz_problem https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d2568... (2020) This section still kind of exists, but it has been toned down a fair bit now that certian issues have been addressed [3]; it now mainly focuses on a couple of specific GNOME issues directly and more broadly addresses NVidia's poor Wayland support relative to some other vendors. ----- [1]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217 [2]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... [3]: https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374d017f47024174072731a29d#why-dont-i-have-any-window-decorations https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374...

lights0123 3y ago

There is no de-facto Wayland software like there is the X.org server. Wayland is just a protocol—KDE and GNOME (through Mutter) both implement it. The author is saying that KDE did so better than GNOME.

djbusby 3y ago

Briefly: it's a big lift for all the different desktop environments (DE) to move from X11 to Wayland. Lots of moving parts; re-implementing and re-factoring is needed.

londons_explore 3y ago
The vast majority of users today run a hybrid of Wayland and XWayland... Getting the worst of both worlds, and extra bugs to go on top...
- nolist_policy 3y ago
  That is not true though, XWayland is better maintained than native Xorg. It is here to stay for backwards compatibility. Disclaimer: I run ChromeOS and Wayland just works.
  - djbusby 3y ago
    Oh, I've got a Chromebook; didn't know it was all Wayland. I'm thinking that it "just works" there because G has more resources to patch all the needed features. More resources than KDE or Gnome or others have available.
    - NekkoDroid 3y ago
      I assume its mostly because how you said they can do it and the impact is really only limited to their system AND chromebooks are to my knowledge way more focused of a UX than what Wayland needs to be able to support so they can be even more opinionated about what they support and how

CuriousCosmic 3y ago

KDE and GNOME roll their own wayland libs for their compositor. These have varying levels of quality with their own unique quirks and bugs. The "gold standard" for wayland at the moment is wlroots which is what basically every other wayland compositor uses. PCSX2 apparently works perfectly fine on wlroots based compositors but has some quirks with KDE wayland and is nigh unusable with GNOME's super janky wayland implementation.

abrouwers 3y ago
Funny, I've used a wlroots environment recently (hyprland), and noticed tearing in animations that I don't have in gnome. So, I guess I'll take "janky" :-)
- gkbrk 3y ago
  I thought tearing was not a thing on Wayland, and every frame was perfect.
  - abrouwers 3y ago
    Sorry, "tearing" isn't the correct word. I use the swipe gesture to "peak" at another workspace - if I have a video playing in that workspace, for example, it'll have artifacts in the playback while I'm mid-swipe. On gnome, the picture is perfect - I can swipe half-way, and the video is playing frame-perfect, as if the workspace was in focus.

DistractionRect 3y ago

Basically Wayland only supports a subset of what X11 could do. It's more scoped and does a good job with what it's supposed to do. That said, the rest of the functionality is now an exercise for desktop environments, and they can (and do) things differently.

LtWorf 3y ago
> does a good job with what it's supposed to do. And anything that people used to do on X11, they are told by zealots that they are wrong and aren't supposed to do that. For example: Not losing all the work every time your windows manager crashes remapping keys Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev) Global shortcuts tunnelling over ssh
- Arnavion 3y ago
  >Not losing all the work every time your windows manager crashes https://news.ycombinator.com/item?id=37509703 https://news.ycombinator.com/item?id=37509703 >remapping keys >Use xinput to change parameters of their input devices (libinput dropped most configuration options present with evdev) Up to the compositor. >Global shortcuts Also up to the compositor. Was added to xdp in https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.GlobalShortcuts.xml https://github.com/flatpak/xdg-desktop-portal/blob/main/data... so it's up to the compositor's xdp impl to provide it. It was created by a KDE dev so I assume KDE implements it at least. >tunnelling over ssh https://gitlab.freedesktop.org/mstoeckl/waypipe https://gitlab.freedesktop.org/mstoeckl/waypipe
  - LtWorf 3y ago
    > Up to the compositor. > Also up to the compositor. Exactly my point! Right there. Thanks.
    - erinnh 3y ago
      What’s your point? You didn’t make it. Before you said that your point was that people tell you you aren’t supposed to do those things. But you are able to remap your keys. Remapping keys has been possible in Wayland for quite a while in any compositor I used. (KDE, Gnome, Sway)

OmarAssadi 3y ago

As noted by other commenters, there are several compositors available for Wayland (essentially the bit that actually implements Wayland). Some are developed independently of any particular desktop environment--like wlroots, labwc, hikari, etc--but some are part of a larger project, such as mutter and kwin (GNOME and KDE, respectively). Most of the time you install some sort of GNOME/KDE + Wayland distro, you'll usually also end up with their compositors, and thus potential quirks specific to their implementations. GNOME's implementation in particular has historically caused a lot of drama relative to some of the others -- be it due to purely accidental, broken support for something, or sometimes intentional opposition to a particular concept that many applications rely/used to rely on, like server-side window decorations [1]. The accidental issues that come with fragmentation of the ecosystem and the intentional decisions by different compositors to not support particular extensions/whatever, like the aforementioned, can cause a fair bit of pain for developers of end-user programs. Users who may be totally unaware of the inherent differences between Wayland and X, who may not know that different compositors exist, who may not even know they are running Wayland, etc, inevitably run into strange issues, and then, understandably, file bug reports. This can get old quickly under normal circumstances. But I imagine it sucks even more when you're maintaining software that is relatively understaffed given its importance. Outside of PCSX2, mpv would be a good example: - It's incredibly popular software on its own, being probably the most popular open-source, cross-platform mediaplayer after VLC. - It's also embedded and used as a base for other applications on a wide variety of systems, ranging from other open-source players that try to integrate more tightly with a given platform--e.g., IINA (macOS), mpv.net (Windows), etc--to proprietary, commercial software, such as a variety of Android players and, importantly, Plex, which uses mpv as the default backend on at least tvOS/iOS/iPadOS. - It's software that needs to deal with pretty low-level graphics and audio stuff, so it's inherently a bit complex, and the available pool of potential contributors shrinks. - It tries to be as lightweight as possible and allow for easy embedding into other applications and porting to different systems, so it has several things working against it: -- It's mostly written in C, making it very easy to build and embed anywhere, but not only is C not the sexiest language in 2023 to many, it's also a hard language for someone without a good grasp to write safe, quality code, particularly for something like mpv. -- It doesn't try to enforce a particular rendering backend--e.g., OpenGL, DirectX, Vulkan, Metal, software, etc--nor a particular UI toolkit. Again, great for someone building on top of it. But it makes things like the change from server-side decorations to client-side significantly more annoying / potentially fundamentally incompatiblew ith the project goals. mpv sits in that perfect anti-goldilocks zone: It's important enough to be a problem if it were to disappear, yet unlike the Linux kernel, not quite important enough to have the funding and hoardes of patches despite the project complexity. It's also low-level enough to need to worry about every display server and platform on the planet, yet not low-level/general enough to have a say in the design decisions (e.g., Wayland membership, I believe, is pretty much limited to compositors and UI toolkits - like QT/GTK). All of that, and probably more, adds up to maintaining a surprisingly important, difficult project with relatively few developers but likely many millions of users, many of whom may not even know you exist; it's thankless yet important work. As a result, unsurprisingly, in addition to the infamous locale rant [2] (unrelated to Wayland), mpv used to have a pretty spicy wiki section entirely dedicated to GNOME's Wayland implementation: - https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d25681ce10cb6fa4c6759aaec063#user-content-I_use_GNOME_Wayland_and_I_have_xyz_problem https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d2568... (2020) This section still kind of exists, but it has been toned down a fair bit now that certian issues have been addressed [3]; it now mainly focuses on a couple of specific GNOME issues directly and more broadly addresses NVidia's poor Wayland support relative to some other vendors. ----- [1]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217 [2]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... [3]: https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374d017f47024174072731a29d#why-dont-i-have-any-window-decorations https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374...