Hacker News Reader

Comment by sprash | Hacker News Reader

The severely limited scope of Wayland forces all DE vendors to reinvent the wheel and basically recreate their own X11. But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered.

Also X11 was never "monolithic" but in reality completely modular. It allows for example to change the window manager or even compositor at runtime without affecting running programs. For this to work your API hast to provide more functionality than your typical Wayland compositor. This is often mistaken for "monolithic" when in fact is actually the complete opposite of monolithic.

View on HN

> But this time it's worse because the APIs are DE/Toolkit specific without the standardization that X11 offered.

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.

> Wayland has some widely-respected values around who gets to introspect what state and who acts as authority

And this is a main problem. These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.

> But there's a lot of value in agreed-upon protocols, and X11 also needed many of them.

Depends on the protocol. Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!

> These "widely-respected values" (by whom actually?) make sure that you can't implement an app that allows dragging tabs from one window to another because windows are not allowed to know their absolute coordinates.

I don't understand why they would need to for a DND operation (or why a custom protocol would be needed - X11 didn't need one for the same use case either).

> Wayland as such has zero value. I still can't decide that is designed by retarded morons ore geniuses as means of sabotage. Either way it destroys the FOSS ecosystem very effectively. Good job!

This comes across as very irate and emotional. I'm glad you care about the FOSS ecosystem this deeply. I do as well, and have spent 20 years of my career working on making it succeed. I'd rather we don't presume malice in each other.

> I'm glad you care about the FOSS ecosystem this deeply. I do as well

As member of KDE e.V. board of directors you were part of the cancel brigade against Richard Stallman which was clearly an OP against FOSS. This means you are either some useful idiot or an actively malicious actor. Either way it would be great if people like you would stop "caring" about the FOSS ecosystem.

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

How do you think Qt draws on the screen ?

Right, but Qt abstracts that interaction so KDE code doesn't have to care about it. The person you're replying to never implied X11 wasn't involved, just that it was abstracted away.

That's a typical view, but I see it as a lot less monolithic because it's using the kernel to do a huge amount of the things X used to do itself.

There's a lot of other concerns (input handling, screen shots, etc cetera) but at the heart Wayland is mostly just a management later for *nix dmabuf's. Mode setting concerns are done by the kernel too. Libwayland mostly uses egl, is my understanding. It invents so much less than X, where-as when X was made, the OS had none of these abstractions to reply on. X was basically the kernel, part 2. Wayland has none of this baggage; in almost all implementations leverages a world of great ready made stuff rather than implementing itself. Source: https://wayland-book.com/surfaces/dmabuf.html

> to reinvent the wheel

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.

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

It sure looks like it's true, or did GNOME/KDE/wlroots manage to agree on a single screenshot API?

Yeah, XDG portals. Not something that's essential to the display protocol.

The idea that we need to be shoving tray icons and screen recording and permissions APIs into the display protocol is an Xism that folks need to let go. The display protocol should only deal with displaying things, meaning it's a standard way to give memory buffers to clients for them to draw into, and all the other crap can and should be handled elsewhere.

Yeah, I'm a fan of it being an optional standard that's separate from the core display protocol. The problem is that it needs to be a standard, not 3 different standards because it wasn't standardized so 3 different groups created their own things, and all of the standards needed to replace X11 as it was actually used should have had a 1.0 spec before the whole mess was shipped to end users, let alone before users were told that this was the future that they needed to get on already.

> They might add some DE-specific protocol for themselves, but I don’t see why that would be a problem.

What Wayland advocates don't see as a problem is the one of the main problems. I see a pattern here.

> years of hard work.

The only thing that takes "years of hard work" is writing a simple native Wayland client that takes screenshots.

https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...

Without knowing much about dbus, or freedesktop I was able to make it work on a lazy afternoon. And it worked for me in wlroots and on gnome, I am assuming kde also implements it. How were you trying to do it that it took so long?

Wayland sounds a bit like what Vulkan is to OpenGL? Am I anywhere close?

I'm a novice when it comes to the implementation of compositors and display servers, but as a user it's been a far better experience than X11/Xorg ever was. Seeing this robustness video just proves it to me even more.

Rather the opposite. Wayland is a far more opaque abstraction layer than X11.

Also the "robustness" is achieved with KDE/Qt specific protocols and as such has nothing to do with Wayland. Similar functionality could be achieved with X11.

X11 can't do this because memory allocations happen in the X server.

DRI3 clients allocate themselves their render buffers. Hence perfectly possible with X11.

>Am I anywhere close?

It's close, but since the services are much simpler you don't run into the problem of needing an older of magnitude of more lines to draw a triangle.

Reply on news.ycombinator.com