QtWayland 6.6 Brings Robustness Through Compositor Handoffs

(0) zero community mind share as a result of extremely cumbersome and developer hostile APIs and the lack of standardization of essential functionality.

QtWayland won't be able to address this because vendor lock-in for a de-facto proprietary toolkit won't generate any community mind share either.

There is no problem with monoliths in itself, if you needlessly introduce IPC at boundaries that don’t need it, you make your life just harder (also, tell that to those who make everything into a microservice). Also, people can use libraries to create better, different implementations, e.g. see wlroots - isn’t that the spirit of open-source instead of a single de facto monolith?

The important thing is that the public API is well-defined.

Also, X has problems and needs replacing because its fundamental architecture got outdated in the last 30 years.

Libraries are a thing

> because the APIs are DE/Toolkit specific

That’s false in itself, what do you think Wayland protocols are? They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem.

> standardization that X11 offered

What standardization? A single implementation that does its thing is not a standard, by definition.

> Also X11 was never "monolithic" but in reality completely modular

But let me guess, you think that systemd is a huge monolith, right? Also, a wm is very trivial compared to the rest, they can easily be a lua extension and that’s it.

X is monolithic, because they had to pry printing and shit out of it over years of hard work.

This has improved quite a bit with nVidia eventually implementing GBM support (so compositors no longer need an nVidia-specific codepath, which is nice). I use Plasma on Wayland on my nVidia-powered ThinkPad, and it's generally fine and has been for some time. That said, the nVidia stack does still feel a bit more hit and miss than some others.

> (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.

These largely have been addressed by newer protocols and infra, although application support and maturity for those protocols in deployed systems is still trailing behind X11. Still, the fundamentals have been worked out, and there's steady progress on spreading the solutions through the ecosystem.

And no, this blog post has nothing to do with either topics but is about unrelated technical innovation in the Wayland space.

On this one: It's not really that different. Very little if any KDE code made any direct calls to Xlib or xcb past the very early years. Most of this was also hidden by Qt abstractions, and toward app/shell devs most certainly by further KDE library abstractions. Directly interacting with X11 was an almost-never occurence.

Fairly similar in other toolkits, since most of them have some sort of cross-platform strategy and infra.

People sometimes have kind of odd notions of how exactly X11 development was different. X11 had its fair share of "fragmented implementations" immaturity. It had its fair share of "this new standard is not widely implemented yet" phases that people just don't remember because they started using it after things had settled down (e.g. NetWM and EMWH protocol extensions did not always exist, and also got interpreted quite differently sometimes, or e.g. the clipboard spec). DEs also did plenty of DE-specific things on X11 using proprietary window hints or DBus-based side channel protocols.

If there's one broad philosophical difference, it's Wayland has some widely-respected values around who gets to introspect what state and who acts as authority, that mean that things that X11 apps could monkey-patch may now require a protocol to be agreed on. But there's a lot of value in agreed-upon protocols, and X11 also needed many of them.