4 ms·

The most important points: - It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all)

by sprash 3y ago

The most important points: - It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all). - We do not have the resources to maintain our own Wayland compositor This should tell you everything. Since the Wayland ecosystem is extremely developer hostile it cements the KDE/GNOME duopoly and eliminates the long tail. XFCE might maybe make the push to Wayland but after that that's it. The rest of the tail is dead.

sho_hn 3y ago
This has already proven to be wrong, imho. There's numerous Wayland versions of popular niche X11 WMs, for example the way sway is a Wayland implementation of i3, and some exciting new experiments (like scrolling tiling WMs) that never really existed on X11. It's usually a lot easier to make a compositor/WM with unusual or innovative behavior on the Wayland stack than it was with X11 in general, as far less behavior is presumed/baked-into either the display server or the existing applications. For example, apps not being able to introspect or manipulate their global coordinates also means the compositor can arrange them however it wants without breaking app assumptions, which enables fancy new layouts. There's prominent libraries that make compositor development easier, for example wlroots and QtWayland -- XFCE is also using wlroots. "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different. The tail looks alive and well.
- yjftsjthsd-h 3y ago
  > "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different. That's a reasonable expectation, but it turns out the slicing does matter. For example: With Xorg, setxkbmap will always work to change the keyboard layout on the fly. Now, wlroots does support configuring the keyboard layout, but it turns out the compositor has to actually hook that functionality up, so if I try out a new compositor that looks neat, I can quickly discover that there's actually literally no way to change the keyboard layout because the developer hasn't gotten around to adding that yet. This is not a hypothetical example.
  - sho_hn 3y ago
    Yes, this is true and a good argument.
- sprash 3y ago
  Proven wrong by whom? Your opinion is obviously severely biased because you get paid for working on Wayland. Job security is obviously the only reason anyone would defend this pile of garbage of an ecosystem. All your suggestions mean replacing X11 functionality with vendor lock-in de-facto proprietary Qt libraries. I can see why your employer likes that. Now get off my lawn.
  - sho_hn 3y ago
    I don't get paid for working on Wayland (nor on Qt). You also didn't engage with any argument.

by sprash 3y ago

sho_hn 3y ago

This has already proven to be wrong, imho. There's numerous Wayland versions of popular niche X11 WMs, for example the way sway is a Wayland implementation of i3, and some exciting new experiments (like scrolling tiling WMs) that never really existed on X11. It's usually a lot easier to make a compositor/WM with unusual or innovative behavior on the Wayland stack than it was with X11 in general, as far less behavior is presumed/baked-into either the display server or the existing applications. For example, apps not being able to introspect or manipulate their global coordinates also means the compositor can arrange them however it wants without breaking app assumptions, which enables fancy new layouts. There's prominent libraries that make compositor development easier, for example wlroots and QtWayland -- XFCE is also using wlroots. "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different. The tail looks alive and well.

yjftsjthsd-h 3y ago
> "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different. That's a reasonable expectation, but it turns out the slicing does matter. For example: With Xorg, setxkbmap will always work to change the keyboard layout on the fly. Now, wlroots does support configuring the keyboard layout, but it turns out the compositor has to actually hook that functionality up, so if I try out a new compositor that looks neat, I can quickly discover that there's actually literally no way to change the keyboard layout because the developer hasn't gotten around to adding that yet. This is not a hypothetical example.
- sho_hn 3y ago
  Yes, this is true and a good argument.
sprash 3y ago
Proven wrong by whom? Your opinion is obviously severely biased because you get paid for working on Wayland. Job security is obviously the only reason anyone would defend this pile of garbage of an ecosystem. All your suggestions mean replacing X11 functionality with vendor lock-in de-facto proprietary Qt libraries. I can see why your employer likes that. Now get off my lawn.
- sho_hn 3y ago
  I don't get paid for working on Wayland (nor on Qt). You also didn't engage with any argument.