Wayland was designed from the point of view of theoretical purists. It's basically "how would a display server work in an ideal world", unfortunately, that design turns out to also be impractical and straight up developer/user hostile.
I would at least like to understand the idea of 'pureness' this API tries to aspire to.
It's definitely not Unix-like, since file handles and writes and epoll, and mmap for IPC are nowhere to be found. Instead you have 'objects' with these lifecycle methods that create/release resources (probably committing the design sin of having these for things which should be pure data, like descriptors).
What's with these XML headers? It's UNIX standard stuff, to have a C API for your code, that declares an API for a library, and then a makefile can just consume it. There's a standard way of supplying, finding and consuming them. Even binding generators are probably more comfortable with C headers, than this XML thing
And what's with the callbacks for everything, like screen resolution queries? In Win32, you can do it with a single synchronous API call that returns a struct that has all the info. It's not like you have to touch the disk or network to get this. In cases where you do, you usually have a call that dispatches a message to another window (which you can also dispatch yourself), and you have to listen to the response.
I did some X11 programming as part of work, and its entirely reasonable and conventional compared to this, much more like Win32 (even maybe a bit more pleasant, but I'm no expert on it).
The API sounds awful (and I've had ChatGPT generate me some example programs, and it's somehow even worse than the author describes), and not only that, the requirement of 'everything be an object', with chains and trees of objects being created introduces a huge source of bugs and bookeeping performance overhead on the application side.
Yes, you do have to do something like this with some things under Windows, but the reason for this is that these objects have duplicates in the Windows kernel.
But here it looks like this is just to satisfy the sensibilities of the designer.
Honestly this sounds like the most epic case of NIH syndrome. Like these guys wanted to write their own OS and userland and break with existing conventions.
Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys. For example, I found this with ~2 minutes of Googling: https://wayland.app/protocols/hyprland-global-shortcuts-v1
> Not impossible, it just needs to be implemented at a different layer. The compositor needs to expose some API for global hotkeys.
That's a big problem. When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland.
At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard no matter what the wayland orgs say about it.
It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.
I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.
And that's a problem, now instead of knowing that something just works in the WM you're using, you have to cross-reference a matrix of features for basic tasks across different WMs because the bare minimum features are not found in the core protocols. Nothing is standardized, it's just a pile of different WMs developing their own sets of custom protocols.
Not only that. A11y is also quite hard. Tools that are simple to implement thanks to good a11y apis - for example on macos, the tool rcmd or homerow - are super hard to do in Wayland.
wdotool exists, and global hotkeys are a thing under wayland, but is desktop dependent. KDE allows it by default, Gnome can be made to do it as well with an extension.
Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.
How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
> Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.
Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
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.
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.
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.
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.
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.
> 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).
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.
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.
Seems like complaining about how difficult to use Win32 and COM are. And they are if you use them directly! You don't do that - you use libraries that others have sweated over, as you did with raylib.
Exactly my impression. And honestly, X11 isn't exactly beautiful like the author is implying. A lot of the same wayland complaints they are putting here apply to X11. The main difference is that wayland is apparently handling the event loop for you while X11 expects you to set that up yourself.
Win32 has exactly the same setup of problems here as wayland does. Moreso because Win32 just gives you back opaque handles which you are expected to keep track of and use the Win32 API to do any meaningful interactions.
The only understandable complaint is that wayland makes it hard for different windows to interact with one another for security. IMO, that's a silly goal to chase after, but that's just me.
A big complaint in TFA is that Win32 is much much easier to use than Wayland is:
>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.
And that comes from the core of how Wayland is designed.
In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.
In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.
The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.
I was going to point out that wayland is a protocol & surely there must be other ways to do this. But your point about mesa expecting wayland-client is a very tight binding here.
Anyone know of exceptions? People who get mesa working anyhow, some way?
It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage.
The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.
> But your point about mesa expecting wayland-client is a very tight binding here.
You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).
Having done some mobile development where app sandboxes have been prevalent for years, it's annoying to deal with but necessary. Given the bad behavior some devs attempt, often ad SDKs trying to perma-cookie users, stealing clipboards, etc, having a platform that can support app isolation seems necessary for normal desktop usage.
Having some kind of access control list or other method of enforcing access rights for windows and clipboards is definitely a good thing.
However, such a thing could be relatively easily added to X11 without changing the X protocol, so this does not appear as a sufficient motivation for the existence of Wayland.
I have not tried Wayland yet, because I have never heard anyone describing an important enough advantage of Wayland, while it definitely has disadvantages, like not being network transparent, which is an X11 feature that I use.
Therefore, I do not know which is the truth, but from the complaints that I have heard the problem seems to be that in Wayland it is not simple to control the access rights to windows and clipboards.
Yes, access to those must be restricted, but it must be very easy for users to specify when to share windows with someone else or between their own applications. The complaints about Wayland indicate that this mechanism of how to allow sharing has not been thought well.
This should have been a major consideration when designing access control and it appears that a lot of such essential requirements have been overlooked when Wayland was designed and they had to be patched somehow later, which does not inspire confidence in the quality of the design.
The point of wayland, though, is that back then 13-year-old you would get an application that "works" but to support myriad things (like HiDPI) you'd have to DIY it. Whereas now, sure a 13 year old perhaps won't write directly to wayland's APIs, but you'll use a library and have a much more globally usable result. And honestly probably have a better time - less effort for the same result, and with a more maintainable project in the long run.
The only problem that has existed is that originally there was a single DPI value, not a different DPI value for each monitor.
This has never created any problem for the people using multiple monitors with the same resolution, but only for the people who have used multiple monitors having different resolutions and who might have not liked the changes in windows size when moving a window from a monitor to another monitor.
That was indeed a problem, but it really affected a rather niche use case and it was also trivial to solve without any change in the X11 design, by just making DPI a per monitor variable, which was done long ago.
So criticizing X11 about a supposed problem with HiDPI is incorrect. I have used only multiple 4k monitors with my PCs, with X11, for more than a dozen years and I never had any problem with HiDPI, with the exception of many Java programs written by morons, which ignore the system settings and which also do not allow the user to change the font used by them. I do not know which is the problem with the Java programmers, but I never encountered programs with such a behavior, except those written in Java. Moreover, the Java programs are also the only that had problems with monitors using 10-bit per color component.
While X11 itself never had problems with supporting HiDPI, at least not in the XFCE that I am using, I heard that other desktop environments have created problems with HiDPI that have nothing to do with X11, by not exposing the X11 DPI settings but providing instead some "window scaling" settings, which is something that I do not know how it is implemented, but there are good chances that it is implemented in a wrong way, judging from the complaints that I have seen. I cannot imagine how one could use correctly a "window scaling" factor, because the font rendering program must know the true DPI value when rendering for instance a 12-point font. If rendering is done at a wrong DPI and then the image is scaled, the result is garbage, so in that case it would not be surprising that people claimed that HiDPI works badly in X11, when in fact it was Gnome or whatever desktop environment was used who was guilty for bad support, not X11. I never had to fight with those desktop environments, but I assume that even those would have worked correctly with HiDPI, when using xrandr to configure X11, instead of using the settings of the desktop environment.
There is nothing "niche" about plugging in a modern (e.g. made within last 5 years) laptop into an external display.
These kind of posts just show how disconnected from reality some of y'all are from what most Linux desktop users nowadays actually need from the desktop platform.
I always plug my laptop into one or two external displays.
Even without configuring distinct DPIs per monitor that was not a problem for me, because on the small screen of the laptop I kept only some less important application, like the e-mail program, while working on the bigger external displays, so I had no reason to move windows between the small screen of the laptop and the bigger external displays.
But like I said, setting a different DPI value for each monitor has been added to X11 many years ago, I do not remember how many.
I do not see why one would want to move windows between the external displays and the laptop, when you have connected external displays, so I consider this a niche use case, i.e. moving windows between small screens and big screens, not having simultaneously big screens and small screens.
Without a per-screen DPI value you cannot control the ratio between the sizes of a window when is moved between the big screen and the small screen, but even when you control the ratio, moving windows between screens of different sizes does not work well because you must choose some compromise, e.g. if you keep the same physical size some windows from the big screen will not fit on the small screen and if you make the windows occupy the same fraction of th screen size they will change their sizes during moving and they will be more difficult to use on the small screen.
But like I have said, this no longer matters as the problem has been solved even for this niche use case. I do not even remember if this problem still existed by the time when Wayland became usable.
This article is complaining about the complexity of creating a simple window in Wayland, which is much easier in Win32. Wayland doesn't make creating "a rather complex application" any easier either. In both cases you would use a framework. Even more so in Wayland, which doesn't provide widgets or standard dialogs at all, while Win32 does.
Creating a simple window in Wayland isn't much harder than in Win32. You get a wl_surface, attach a wl_buffer to it, wrap it with xdg_toplevel and handle some callbacks for resizing etc. There's some boilerplate that allows all this to be extensible in backwards-compatible ways, but nothing complex, really. simple-touch example in Weston repository has about 400 lines.
Some compositor's insistence on CSD can make it a bit more complex since you get that in Win32 for free, but on the sane ones you just add xdg-decoration and you're done.
Also, this is all apples-to-oranges anyway, as Win32 is a toolkit, while wayland-client is just a protocol (de)serializer.
The separate process for clipboard: yep... I'm having to do this to be able to get the cursor position myself in Wayland... (This is for a screen recorder app)
As a user, I like wayland. X11 was a security disaster. Wayland is much better about tearing.
What scares me though are all the responsibilities passed to compositors, because what ends up happening is that each compositor may reimplement what should be common functionality in annoying ways. This is especially true for input things, like key remapping. This ultimately fragments linux desktop experiences even harder than it was before.
Huh. The "security" preventing me from doing things I want to do is a major reason I dislike Wayland :/. (e.g. automation & scripting / input events, clipboard, ...)
It also has noticeable mouse lag for me, I really hope this isn't due to avoiding tearing.
That's a nice quip, but what does it mean in this case? If you remove "insecure" or "dangerous" features that people actually need from software, what you achieve is people using other software, and thus you have failed your responsibility?
Win32 has managed to do this without any API change, all the existing APIs work. The same approach would've worked for X11.
What it does is simple - all the functions that deal with windows/handles or events simply do not work on ones that you don't have access to, for example, the EnumWindows function allows you to wall through the tree of windows simply do not see the ones the process has no access to. SetWindowsHookEx which allows you to intercept and modify messages meant for other windows simply doesnt fire for messages you're not supposed to access.
Granted, outside of UWP apps, the application of security is rather lax (this is for legacy purposes, the security's there, just not enforced), but for apps running as admin, or UWP apps, the sandboxing is rather solid.
IMHO the security advantage of Wayland is mostly a myth and probably the same is true regarding tearing. The later is probably more an issue with respect to drivers and defaults.
This only matters if you compare properly sandboxed apps, otherwise an app that runs with your uid can still do harm and practically indirectly completely compromise the system..
Are most flatpaks _properly_ sandboxed? Of course not.
And X11 always had a mechanism for isolating clients as well, i.e. trusted and untrusted clients. Nobody used it because it was irrelevant before sandboxing.
Linux always has been a system were the existence of malware was ignored, specially Desktop, contrary to other OSes (tooling included). But since a couple of years ago can be observed (I observe) slooow movements trying to correct this colossal mistake.
If this is the best way to do it or not, I do not enter. I particularly just welcome most of the advancements about this matter in Linux due such absence of worrying, keeping my fingers crossed that the needed tooling arrives on time (ten years behind Windows, I think).
Letting any GUI application capture all input and take full control of the desktop completely defeats the point of sandboxing and X11 does exactly that.
Sandboxing defeats the point of said applications. If you want your computer to have no functionality, check out Figma. A clickable prototype sounds like precisely the security the world needs right now.
So accordingly, ActiveX was a brilliant idea and any web page should be able to execute code in the kernel context, otherwise no meaningful functionality can be provided
Yawn, X11 (and similar "unsecure" desktop environments) existed for half a century and the sky hasn't fallen. I'm tired of that "will somebody think of the children/grandparents" scare mongering.
It hasn't, but Windows has had its fair share of keyloggers, RATs, and so on, and I think we can all agree that anti-virus software is an inherently flawed concept.
The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.
I have used quite a bit of Gtk and QT, and have had to touch X11 or Wayland very little directly, EXCEPT for one case where I wanted to provide a global hotkey...
Which is kind of understandable as Wayland tries to be more secure: and thus in Wayland not all keyboard events are propagated to all applications (that's what X11 does). I think it's a good idea to put security first in this iteration of FLOSS desktop technology.
Phoenix[0] has some good ideas about how X11 could be made more secure without breaking backwards compatibility. I don't understand what was so fundamentally broken about X11 as a protocol that it required a replacement protocol.
We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation.
Well kind of. It'll be several decades before we see any practical benefits - at the moment once you have local execution you can do anything you want - accessing other apps or even root is trivial.
...which is overkill when you only need a Vulkan or GL canvas which spans the windows client area... and even with GTK or Qt your app still stands out like a sore thumb on the "other" desktop environment because the window chrome doesn't match the rest of the system.
That just moves the problem to the GLFW maintainers. The point is that the Wayland designers should have learned from the mistakes of 40 year old APIs, but they are not only repeating the same problems, they made it even worse. That's quite an achievement tbh.
I sidestep by using neovim as my environment for pretty much everything and you can bridge the SPICE virtio clipboard channel to Wayland. You can get clipboard sharing to work natively on wlroots compositors.
Tbh, 1300 lines of extremely cursed code to open a frigging window and GL context deserves that bile. Such a fundamental problem is also nothing that can be fixed through contributions except discarding the whole clusterfuck and starting over from scratch.
No, nothing deserves this constant whining and crying day in and day out.
Especially coming from people who don't put in the work to build something else.
It's really bizarre how the opensource community degraded into this space of constant aggresive, insulting screeching over every single project thats actually moving something in the Linux world. Coming from people who don't put any code behind it or do anything but attack any change since 1990s.
To hell with that, Linux developers deserve better than this constant barrage of hate.
Tbh, it's quite delusional to think that a better alternative solution would win that's not backed by Redhat and GNOME. In a purely competitive environment, a design like Wayland could never have "won" as an X11 replacement, it was pushed long enough until it was "too big to fail".
You should know that the constant criticism is basically what stabilized systemd - the core - and stopped systemd - the project - from stretching its arms over every component in the ecosystem, which obviously could create a single-point-of-failure. The upstream has made and still makes stupid assumptions that are totally denied by distros. You’re basically missing a lot of details here.
I'd argue the Wayland hate is much worse. Not that it might be bigger than the hate on systemd, but contrary on the case of the systemd, there are no other real alternatives to wayland nor x. Wayland is attempting to improve over x but some (really noisy) people just suffer from fear of the new.
Yeah Wayland I get. It's still kind of janky even after almost 20 years. Complaining about Systemd makes no sense though. It works very reliably, switching to it caused no issues, and it has fixed a number of problems with the Linux desktop.
But haven't you heard that systemd is an evil project made by Microsoft to somehow destroy Linux and make everyone use Windows? It must be true because I saw it on Reddit.
People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).
People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).
And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.
The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).
Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?
By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.
Reminds me somewhat of Vulkan. I think the trend of making the actual specification of something lower level and less convenient is rather logical. Why burden implements with a load of convenience functions when that could be left up to libraries?
Because those libraries will not materialize in time, and more importantly the hobbyists who are supposed to write those libraries don't have the testing capabilities of large organizations (e.g. testing across hundreds of hardware configurations).
...or worse, the libraries do get written, but multiple times in mutually-incompatible forms that are tightly coupled to specific compositors / desktop environments. (Screengrabbing, anyone?)
It's definitely not Unix-like, since file handles and writes and epoll, and mmap for IPC are nowhere to be found. Instead you have 'objects' with these lifecycle methods that create/release resources (probably committing the design sin of having these for things which should be pure data, like descriptors).
What's with these XML headers? It's UNIX standard stuff, to have a C API for your code, that declares an API for a library, and then a makefile can just consume it. There's a standard way of supplying, finding and consuming them. Even binding generators are probably more comfortable with C headers, than this XML thing
And what's with the callbacks for everything, like screen resolution queries? In Win32, you can do it with a single synchronous API call that returns a struct that has all the info. It's not like you have to touch the disk or network to get this. In cases where you do, you usually have a call that dispatches a message to another window (which you can also dispatch yourself), and you have to listen to the response.
I did some X11 programming as part of work, and its entirely reasonable and conventional compared to this, much more like Win32 (even maybe a bit more pleasant, but I'm no expert on it).
The API sounds awful (and I've had ChatGPT generate me some example programs, and it's somehow even worse than the author describes), and not only that, the requirement of 'everything be an object', with chains and trees of objects being created introduces a huge source of bugs and bookeeping performance overhead on the application side.
Yes, you do have to do something like this with some things under Windows, but the reason for this is that these objects have duplicates in the Windows kernel.
But here it looks like this is just to satisfy the sensibilities of the designer.
Honestly this sounds like the most epic case of NIH syndrome. Like these guys wanted to write their own OS and userland and break with existing conventions.
That's a big problem. When things become an optional extension for a compositor, that means you cannot reliably deploy something that depends on it to Wayland.
At this moment, things in the wild are coupling themselves to libwayland-client and in practice ossifying its ABI as a standard no matter what the wayland orgs say about it.
I'm not happy with how the collaboration and planning between various parties involved went over years and I do believe that a lot of these adoption pains are fully self-inflicted, but that has absolutely nothing to do with Wayland's technical design.
Do you mean the Window Manager layer?
That sounds like a different way of saying "impossible".
In X11 I can create an automation tool that works regardless of the underlying WM, or even if there isn't an underlying WM.
Can't do that with Wayland.
Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things.
Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
https://github.com/ReimuNotMoe/ydotool
The extra security meant many automation tasks need to be done as extensions on composer level making this even worse
When designed by committee.
With conflicting interests.
And Veto Powers.
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.
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.
Not to draw any specific analogy, but sometimes a fussy low-level interface is just important to have.
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
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.
Win32 has exactly the same setup of problems here as wayland does. Moreso because Win32 just gives you back opaque handles which you are expected to keep track of and use the Win32 API to do any meaningful interactions.
The only understandable complaint is that wayland makes it hard for different windows to interact with one another for security. IMO, that's a silly goal to chase after, but that's just me.
>Getting any example application to work is so incredibly ridiculous, that every second I program on Wayland, I yarn for the times I did Win32 programming.
And that comes from the core of how Wayland is designed.
In Win32, the stable interface / ABI is the set of C functions provided by the operating system through DLLs. These are always dynamically loaded, so Microsoft is free to change the internal interface used for controlling windows at any time. Because of this, decades-old .exes still run fine on Windows 11.
In Wayland, the stable interface is the binary protocol to the compositor, in addition to the libwayland-client library plus extensions. Instead of that socket being an "implementation detail", it's now something that all programs that just want to make a window have to deal with. You also can't just use the socket and ignore the libwayland libraries, because mesa uses libwayland-client and you probably want hardware acceleration.
The other big issue is the core Wayland protocol is useless; you have to use a bunch of protocol extensions to do anything, and different compositors may implement different versions of them. On Win32, Microsoft can just add another C function to user32.dll and you don't have to think about protocol how that gets transformed into messages on the socket layer, or compatibility issues with different sets of extensions being supported by different compositors.
Anyone know of exceptions? People who get mesa working anyhow, some way?
It also doesn't preclude people from making nicer experiences on top of libwayland. Again I'd be curious to see what material is out there. It feels like a library that materializes the current state of things into a local view would go a long way to dispel the rage of people such as the author here, who seem to detest callbacks with firey rage.
The idea of the wayland registry seem unifying & grand to me. Ok yes it's async & doesn't hide it? Lot of ink spilled to be upset about that, and doesn't feel like an immutable fact that must govern life, if that for some reason makes you as mad as this dude.
You don't have to use Mesa's wayland-egl to make EGL work with Wayland, you can easily pass dmabufs by yourself - though this will theoretically be less portable as dmabufs are Linux specific (but practically they're also implemented by various BSDs).
However, such a thing could be relatively easily added to X11 without changing the X protocol, so this does not appear as a sufficient motivation for the existence of Wayland.
I have not tried Wayland yet, because I have never heard anyone describing an important enough advantage of Wayland, while it definitely has disadvantages, like not being network transparent, which is an X11 feature that I use.
Therefore, I do not know which is the truth, but from the complaints that I have heard the problem seems to be that in Wayland it is not simple to control the access rights to windows and clipboards.
Yes, access to those must be restricted, but it must be very easy for users to specify when to share windows with someone else or between their own applications. The complaints about Wayland indicate that this mechanism of how to allow sharing has not been thought well.
This should have been a major consideration when designing access control and it appears that a lot of such essential requirements have been overlooked when Wayland was designed and they had to be patched somehow later, which does not inspire confidence in the quality of the design.
The only problem that has existed is that originally there was a single DPI value, not a different DPI value for each monitor.
This has never created any problem for the people using multiple monitors with the same resolution, but only for the people who have used multiple monitors having different resolutions and who might have not liked the changes in windows size when moving a window from a monitor to another monitor.
That was indeed a problem, but it really affected a rather niche use case and it was also trivial to solve without any change in the X11 design, by just making DPI a per monitor variable, which was done long ago.
So criticizing X11 about a supposed problem with HiDPI is incorrect. I have used only multiple 4k monitors with my PCs, with X11, for more than a dozen years and I never had any problem with HiDPI, with the exception of many Java programs written by morons, which ignore the system settings and which also do not allow the user to change the font used by them. I do not know which is the problem with the Java programmers, but I never encountered programs with such a behavior, except those written in Java. Moreover, the Java programs are also the only that had problems with monitors using 10-bit per color component.
While X11 itself never had problems with supporting HiDPI, at least not in the XFCE that I am using, I heard that other desktop environments have created problems with HiDPI that have nothing to do with X11, by not exposing the X11 DPI settings but providing instead some "window scaling" settings, which is something that I do not know how it is implemented, but there are good chances that it is implemented in a wrong way, judging from the complaints that I have seen. I cannot imagine how one could use correctly a "window scaling" factor, because the font rendering program must know the true DPI value when rendering for instance a 12-point font. If rendering is done at a wrong DPI and then the image is scaled, the result is garbage, so in that case it would not be surprising that people claimed that HiDPI works badly in X11, when in fact it was Gnome or whatever desktop environment was used who was guilty for bad support, not X11. I never had to fight with those desktop environments, but I assume that even those would have worked correctly with HiDPI, when using xrandr to configure X11, instead of using the settings of the desktop environment.
These kind of posts just show how disconnected from reality some of y'all are from what most Linux desktop users nowadays actually need from the desktop platform.
Even without configuring distinct DPIs per monitor that was not a problem for me, because on the small screen of the laptop I kept only some less important application, like the e-mail program, while working on the bigger external displays, so I had no reason to move windows between the small screen of the laptop and the bigger external displays.
But like I said, setting a different DPI value for each monitor has been added to X11 many years ago, I do not remember how many.
I do not see why one would want to move windows between the external displays and the laptop, when you have connected external displays, so I consider this a niche use case, i.e. moving windows between small screens and big screens, not having simultaneously big screens and small screens.
Without a per-screen DPI value you cannot control the ratio between the sizes of a window when is moved between the big screen and the small screen, but even when you control the ratio, moving windows between screens of different sizes does not work well because you must choose some compromise, e.g. if you keep the same physical size some windows from the big screen will not fit on the small screen and if you make the windows occupy the same fraction of th screen size they will change their sizes during moving and they will be more difficult to use on the small screen.
But like I have said, this no longer matters as the problem has been solved even for this niche use case. I do not even remember if this problem still existed by the time when Wayland became usable.
Some compositor's insistence on CSD can make it a bit more complex since you get that in Win32 for free, but on the sane ones you just add xdg-decoration and you're done.
Also, this is all apples-to-oranges anyway, as Win32 is a toolkit, while wayland-client is just a protocol (de)serializer.
It's absolutely trivial in comparison. Same thing with Xlib; < 100 lines of C code is enough for a simple app.
What scares me though are all the responsibilities passed to compositors, because what ends up happening is that each compositor may reimplement what should be common functionality in annoying ways. This is especially true for input things, like key remapping. This ultimately fragments linux desktop experiences even harder than it was before.
It also has noticeable mouse lag for me, I really hope this isn't due to avoiding tearing.
What it does is simple - all the functions that deal with windows/handles or events simply do not work on ones that you don't have access to, for example, the EnumWindows function allows you to wall through the tree of windows simply do not see the ones the process has no access to. SetWindowsHookEx which allows you to intercept and modify messages meant for other windows simply doesnt fire for messages you're not supposed to access.
Granted, outside of UWP apps, the application of security is rather lax (this is for legacy purposes, the security's there, just not enforced), but for apps running as admin, or UWP apps, the sandboxing is rather solid.
This only matters if you compare properly sandboxed apps, otherwise an app that runs with your uid can still do harm and practically indirectly completely compromise the system..
Are most flatpaks _properly_ sandboxed? Of course not.
Linux always has been a system were the existence of malware was ignored, specially Desktop, contrary to other OSes (tooling included). But since a couple of years ago can be observed (I observe) slooow movements trying to correct this colossal mistake.
If this is the best way to do it or not, I do not enter. I particularly just welcome most of the advancements about this matter in Linux due such absence of worrying, keeping my fingers crossed that the needed tooling arrives on time (ten years behind Windows, I think).
Sandboxing defeats the point of said applications. If you want your computer to have no functionality, check out Figma. A clickable prototype sounds like precisely the security the world needs right now.
The only thing keeping those away from Linux was its market share. With npm malware on the rise, this is no longer enough of a protection.
> Make easy things easy. Make hard things doable.
is generally unachievable. Instead, pick one:
- easy things easy, hard things impossible
- easy things tedious, hard things possible
(Unless you want to maintain two sets of interfaces in parallel.)
We can argue about limitations of X.org's implementation of the X server, but, as demonstrated by Phoenix, X.org doesn't have to be the only X server implementation.
[0]: https://git.dec05eba.com/phoenix
It's getting a bit boring, especially since none really does more than complain.
Especially coming from people who don't put in the work to build something else.
It's really bizarre how the opensource community degraded into this space of constant aggresive, insulting screeching over every single project thats actually moving something in the Linux world. Coming from people who don't put any code behind it or do anything but attack any change since 1990s.
To hell with that, Linux developers deserve better than this constant barrage of hate.
Some people just wanna complain
Some people just want to live in the 80s forever.
I think this shaming of free software users that want to make other choices is rather terrible.
People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).
People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).
And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.
The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).
Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?
By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.
It satisfies the requirement to "make easy things easy, make hard things doable" and it also gets you cross platform support.
https://www.youtube.com/watch?v=HMKaM3FdsgY
Because those libraries will not materialize in time, and more importantly the hobbyists who are supposed to write those libraries don't have the testing capabilities of large organizations (e.g. testing across hundreds of hardware configurations).
So I feel your pain. I did hear programming for Wayland is harder than X11, but I never did either so I have no idea if that is true.