alt Hacker NewsI 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.
Replies
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.
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.
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.