I agree that the lack of standardization around the "insecure" things is a bad idea. Insecure operations don't have to be available by default, or even universally supported, but a central registry of interfaces for e.g. retrieving all windows on a desktop would certainly help preventing fragmentation.

At the same time, most of this post really is just a rant essentially saying that a low-level library is so flexible that using it directly results in code so verbose it can hardly be read. Yes, that's how good low-level designs always are.

You can turn a generic portable asynchronous ANSI C interface into a simple, blocking and platform-specific one with an abstraction layer. You can integrate it with all sorts of existing event loops and programming frameworks. You can customize it all you like but using it directly in an application will cost you a lot of patience. At the same time, you can't go in the opposite direction; from a "simple" blocking black-box interface to something that can reasonably host a complex GUI toolkit. If you're after simplicity, go higher-level.

▲

flohofwoe 16 hours ago | parent | next [-]

There is really no excuse for a low-level API to be hard to use. It's just poor API design, plain and simple.

At the very least there should be a standardized (and centralized) client library on top of Wayland but below widget frameworks like GTK or Qt which implements the missing "desktop window system features": opening, moving, sizing windows (with decorations please), mouse and keyboard input events, clipboard, drag-and-drop. Non-GTK/Qt applications should never have to talk directly to the asynchronous Wayland APIs, only to this wrapper library.

Such a library should be designed to make programmers want to move on from X11 (because writing code against Xlib is horrible, but somehow Wayland managed to be even worse) - and tbh, this new window system client library (at first on top of X11) should have been the top priority of the Wayland project before starting to work on the actual X11 replacement, and it should have shipped on all desktop Linux distros at least a decade ago so that application programmers could have been won over (and for collecting feedback) even before Wayland shipped its first version.

▲

vimredo 15 hours ago | parent [-]

I might be mistaken, but isn't this what libraries like winit exist for? It might not be just for wayland, but it seems like it supports everything you mentioned other than drag and drop.

▲

flohofwoe 15 hours ago | parent [-]

Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs). This client library should really be a mandatory part of each Wayland install as a system library, not part of the application. And most importantly, the Wayland project needs to start eating their own dogfood, or things will never improve.

	▲	tuna74 12 hours ago \| parent [-]
		"Generally yes (or GLFW, or SDL), but the Wayland project shouldn't delegate the job to burned out hobbyists (who will think twice before wasting their time with bad APIs)." Who do you think work on the various parts in Wayland if not "burned out hobbyists"?

▲

i80and 16 hours ago | parent | prev | next [-]

Whenever people complain about Wayland being hard to program in, I think about how Xlib was largely replaced by XCB, and OpenGL is increasingly marginalized in comparison to Vulkan.

Not to draw any specific analogy, but sometimes a fussy low-level interface is just important to have.

▲

flohofwoe 16 hours ago | parent | next [-]

> and OpenGL is increasingly marginalized in comparison to Vulkan

Vulkan's "API design deficits" (to put it mildly) have been recognized by Khronos though, and turning that mess around and making the API a "joy to use" is one of Khronos' main priorities at the moment (kudos to them for doing that).

https://www.phoronix.com/news/Vulkan-Joy-To-Use-2025

	▲	i80and 15 hours ago \| parent [-]
		That's good to hear!

▲

aninteger 15 hours ago | parent | prev [-]

XCB did not largely replace Xlib. In fact, some (all?) implementations of Xlib are built on top of XCB.

	▲	i80and 15 hours ago \| parent \| next [-]
		Maybe the technical politics have changed, but I feel like I remember there was some push in the late 2000s to rewrite libraries that were using Xlib to instead use XCB. Regardless, that's sort of my point: having a lower level fiddly layer is a desirable quality, and Xlib being rebased on top of it isn't exactly a counterexample.
	▲	seba_dos1 15 hours ago \| parent \| prev [-]
		Turns out you want to build higher-level interfaces on top of lower-level interfaces, not the other way around.

▲

torginus 16 hours ago | parent | prev [-]

The API design has nothing to do with security. The Posix API is completely secure. MS has been able to bolt on exactly this kind of security to Win32.