4 ms·

The problems don't change the fact that it's better & smarter & obvious, and honestly the problems here are... frequently misstated ("Wayland provides no captur

The problems don't change the fact that it's better & smarter & obvious, and honestly the problems here are... frequently misstated ("Wayland provides no capture APIs"... uhhhh what? this ticket is closed & resolved >2 years ago & webrtc for example works fine.). Leaving X to have a massive rats nest of drivers, and giving every app supreme access to the session, was a terrible situation, and Wayland is a reasonable, far lower surface-area alternative that's far more sensible & leaves far more responsibilities in the kernel's trusting hands. This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread. What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example. Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem. That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.

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

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