[immibis]

Because Wayland is worse than X11. Unfortunately, it is true that sometimes after your software design gets worse it gets better, but other times after it gets worse it gets worse. It's not correct to assume that something will get better just because it is currently worse.

[ahartmetz]

Wayland went for minmalism because one can always add things later. Unfortunately, making additions in a multi-desktop environment turned out to be kinda difficult.

In a way, the quality of the design (and implementation) is fine, but the quantity of features is insufficient and limited by social issues.

It's basically the opposite problem of systemd.

[immibis]

Wayland is not trying to do enough. You can send pixels to a compositor - great. It turns out a desktop is more than just pixels sent to a compositor. It turns out X11 has a lot of stuff because there is a lot of stuff to do. It could be simplified somewhat, producing incompatible X12, but not simply thrown away along with all the accumulated knowledge. It's literally the Joel Spolsky "never rewrite Netscape" effect in action. Wayland has now spent nearly a decade reaccumulating a part of the same knowledge that was already known, but worse.

[sylware]

wayland annoys the toxic people, because it is currently favoring easy alternative implementations.

It won't last, probably.

Those toxic people usually always get their way into "core", pouring tons and tons of interfaces and dirty everything, viciously adding "features" to provoke some level of planned obsolescences over some few years cycles.

Pure evil.

[ahartmetz]

I'm not sure who you are being sarcastic about in the end, but yes, Wayland is indeed clean and simple enough to not particularly discourage alternative implementations.

[sylware]

Huh.

Indeed, we agree.

We just need to do the hardest part: keep it clean and simple to not particularly discourage alternative implementations... on the long run.

[immibis]

For example, it's vitally important that wayland resists adding features like title bars, window icons, resize handles, desktop icons, or mouse cursors. These frivolous features have no place in a serious desktop environment! They are only bloat!

[ahartmetz]

...while also doing what users want and expect.

[sylware]

... while avoiding their tantrums which will most likely destroy that "clean and simple".

[sylware]

It seems the other way around: x11 got worse and worse, then wayland happened (wayland core).

[immibis]

In what way did X11 get worse and worse? It's one of the most stable protocols in use - outliving HTTP, IIRC. It didn't change - our expectations did. Sure, there are incremental improvements to be made, and incremental improvements that have been made, all of which are optional and therefore couldn't have made it worse.

[sylware]

x11 is absurdely gigantic and dirty compared to core wayland.

We can implement an alternative of a real-life wayland compositor reasonably. A real-life alternative xserver+window manager is not on the same order of magnitude in terms of work.

That reason alone is enough, but if you dig a bit deeper you'll find more reasons to drop x11: you don't need external libs, code is static, x11 bazillion of libs is an abomination of ABIs, much better emphasis on interfaces being optional, etc. For us, wayland is not planned obsolescence, we mean core wayland from a few years ago. We am expecting sabotage by toxic people pouring tons of interfaces in "core" (like they are doing for vulkan3D sabotage... and what they did for x11).

We am still running native x11, only because we run the steam client and only because of that (like 32bits support code).

We are expected to write our own wayland compositor (linux dmabuf, plain and simple C99), then we will have to suffer xwayland for the sake of that horrible steam client, because we have a sin: we play native (#noproton) elf/linux games.

[magicalhippo]

Sure, X11 was getting long in the tooth and not well fit for the modern desktop.

However, the main problem is that the replacement isn't a replacement. If X11 was a pickup truck, Wayland is a bare engine and transmission package.

Sure it might be a much better engine with cleaner design and has no trouble passing emissions testing, and the transmission has much better efficiency and smoother gear shifts. But if you need a pickup truck then it's just one, albeit important, piece.

By leaving all that extra work up to the individual compositors only reinforces the negative aspects of open source fragmentation.

[immibis]

Huh? You don't need libs to use X11. You can just open a socket and send messages. And thanks to the protocol actually defining most of the message IDs you don't even need as much nonsense. 60% of that "bloat" in X11 is stuff Wayland actually needs, and lacks, making it a failure until it gets them. 75% of the rest isn't harming anyone, besides the trees the extra documentation is printed on.

Have you implemented a Wayland compositor by yourself? Without libs?

Desktop systems having desktop system calls is not "sabotage" any more than Linux having open and close syscalls is "sabotage". At some point you have to draw lines in the sand, and say which stuff is in scope and which stuff is out of scope. A useful API does things, which means there have to things in scope. You can't leave everything as an optional extension unless you are defining some kind of absolutely generic message transport layer with absolutely no semantics (not even message ordering or reliability). Is Wayland a protocol for making GUIs appear on the screen, or a protocol for launching nuclear missiles? Right, so it should have features that are relevant to making GUIs appear on the screen. These are core features. "Make a GUI appear on the screen" is a core feature of Wayland even if you pretend it isn't. By requiring the use of five extensions to do that, you do not make anything simpler or more modular, because they are interdependent. You do not increase compatibility, because now you have effective compatibility profiles based on extension sets that are equivalent to protocol version numbers except you didn't call them that. You just make the compatibility story more complicated for no benefit. Abdication of responsibility for a thing doesn't make that thing unnecessary.