4 ms·

I guess what I never understood about Wayland is how they managed to ignore some very obvious problems X11 had, and created brand-new ones. The fact there was

by hakfoo 4y ago

I guess what I never understood about Wayland is how they managed to ignore some very obvious problems X11 had, and created brand-new ones. The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there. The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15). Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows. A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.

wmf 4y ago
The fact there was no default widget kit is the big one for me. This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained). The movement from "window manager" to "compositor" is a huge scope creep. It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it. Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
- kaba0 4y ago
  > Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%. But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead. Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)
rektide 4y ago
> A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. ... I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo. Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time. Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen. Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too. Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.) > I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it. I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation. > The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
kaba0 4y ago
I don’t know why should a window manager care about frameworks, possibly besides window decorations, but that is unique to each one. What if I want a simple framebuffer on the screen? I believe wayland’s solution is much more minimalist and elegant, you get a rectangle and whatever you draw over it I’ll show. Frameworks are very complex beasts, very much outside the scope of a wm protocol. And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath. Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.
halo37253 4y ago
X11 was designed for use as a remote session. Largely built for Unix, these Unix machines we largely accessed remotely. Local Machines were not as powerful as the mini computers of the time that would run the more heavy duty applications. Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s. X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for. For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.

by hakfoo 4y ago

wmf 4y ago

The fact there was no default widget kit is the big one for me. This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained). The movement from "window manager" to "compositor" is a huge scope creep. It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it. Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.

kaba0 4y ago
> Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%. But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead. Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)

rektide 4y ago

> A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. ... I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo. Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time. Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen. Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too. Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.) > I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it. I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation. > The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).

kaba0 4y ago

I don’t know why should a window manager care about frameworks, possibly besides window decorations, but that is unique to each one. What if I want a simple framebuffer on the screen? I believe wayland’s solution is much more minimalist and elegant, you get a rectangle and whatever you draw over it I’ll show. Frameworks are very complex beasts, very much outside the scope of a wm protocol. And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath. Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.

halo37253 4y ago

X11 was designed for use as a remote session. Largely built for Unix, these Unix machines we largely accessed remotely. Local Machines were not as powerful as the mini computers of the time that would run the more heavy duty applications. Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s. X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for. For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.