It means that Wayland is the worst and most idiotic graphics API ever conceived. Talking to Wayland's "asynchronous object oriented protocol" directly is a fucking disaster [1]. Secondary and partly duplicated infrastructure in form of a dbus infested maze of "Desktop-Portals" is necessary to do things as simple as taking screenshots.

As such it essentially cements the GTK/Qt duopoly. Both are extremely subpar low-quality bloated toolkits that are also responsible for the fact that the Linux desktop is still not a thing in 2026.

1.: https://www.p4m.dev/posts/29/index.html

Wayland isn't really a graphics API, it's just a protocol for clients to communicate with the compositor. Sure, there's a lot of boilerplate to get a window on the screen, but you also aren't supposed to use it directly if you want something super simple. It's really meant to be a low level interface for toolkits to be built on top of. Here are two disagreements I have with the linked article:

1. Comparison with raylib

This is imo comparing apples with oranges. Raylib sits at a much higher level than wayland, and it in fact supports using wayland as a backend.

2. Wayland is littered with callbacks because it's an object oriented protocol

It's more due to wayland being an asynchronous protocol. When you send a request to the compositor, chances are that you wont hear back from it immediately. But it's also likely that the app can do other things while waiting for the response. X11 is also in fact an asynchronous protocol, it's just that XLib creates a synchronous API on top of it (and as a result suffers from unnecessary roundtrip delays). In comparison, the newer XCB library is a lot more faithful in terms of preserving the asynchronous nature of the protocol and is used by, for example, Qt's X11 backend and even XLib itself. Of course that also makes it more difficult to use, not unlike libwayland, but the main takeaway here is that you can build a sync API on top of an async one if you wish and not vice versa.

I think some parts of the author's frustration is misplaced because they see libwayland as a toolkit, and in that case yeah it's pretty painful. But I really don't agree with the conclusion that this somehow makes it a bad foundation to build upon. As an analogy, making raw syscalls to the kernel is also painful, but that's why libraries exist.

(edit for better formatting)

Once you set permissions the screenshot taking program always has them and you don't have to do grants more than once.

I agree the portals thing is a horrid mess, but you don't need them to take a screenshot unless you're a sandboxed application. Which is probably a good thing.

You can write a simple Wayland screenshot app with a few hundred lines of code[0], and a compositor that supports the ext-image-capture source and ext-image-copy-capture extensions implemented. (Or the older wlr-screencopy.)

I have plenty of criticism for Wayland and its ecosystem, but if you're going to criticize, don't spread FUD.

(I don't like being the guy who has to assert his credentials, but: I've implemented all three of those screenshot/screencast protocols in a Wayland compositor, just a month or so ago, and know how they work, and what it takes to talk to them from a client.)

Also I read through the link you posted. There's a lot of truth to many of those frustrations, but a lot of it is based on misunderstandings of what Wayland actually is. Yes, most people should be using a toolkit. No, it's not great that the main choices are GTK and Qt. I think there's absolutely room for a mid-level toolkit that lets you do the basics without requiring all the Wayland boilerplate. smithay-client-toolkit is one such effort, and I think it's a good start, though something even higher-level on top of it would be nice.

I also don't get the callback hate. I much prefer registering callbacks over a ginormous switch statement that has to dispatch every event under the sun. Toolkits use callbacks too; does the author hate all toolkits as well? You actually could talk to a Wayland compositor with a big switch statement if you wanted, though you'd need to modify libwayland-client to return events as you iterate its event queue rather than dispatch things to callbacks. That could be a fun project for someone who wanted to make Wayland event handling just like libX11 event handling. (See: just a fundamental misunderstanding of what Wayland is.)

And comparing raylib to libwayland-client is silly; they're fundamentally different things. And you can use raylib to talk to a Wayland compositor. It's just a bad-faith argument.

If you want to compare libwayland-client to something, you have to compare it to libX11 or libxcb. And while yes, getting a simple window on-screen is indeed simpler with libX11/libxcb, doing anything more complicated than that is on par with what you'd end up doing with libwayland-client.

[0] Not counting the protocol code that wayland-scanner will generate for you, because that's like saying you have to count the lines of code in libX11 to write an X11 screenshot app.