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.
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.
I can't count the number of things that either no longer work or no longer even exist at all because of nothing other than the fragmented and ever-changing nature of the web. Aside from sites and apps that required flash or silverlight, I have several different pieces of expensive aactual hardware that either partially or wholly became unusable because the built in and non-updatable web interface requires an old version of java or activex.
Indeed we do all know how that went. It went like to total dogshit.
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.
This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.
Instead of implementing it one way that works forever with any WM/DE (X11), now you must rely on each individual wayland compositor to implement one or more optional extensions correctly, and constantly deal with bug reports of people that are using unsupported or broken compositors.
bindsym $mod+r exec obs-control toggle-recording
If your disdain for desktop isolation is so great, you needn't even use D-Bus. Registering a simple UNIX socket that accepts commands would work equally well in this case.
What's really desired here is a standard way for programs to expose user-facing commands to the system, which is clearly not within the scope of the specification for a display server. The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user, and so many apps have become reliant on this and developers have neglected the creation of portable ways to achieve these objectives. A new specification for display servers that excludes this harmful behaviour is a clear long-term positive.
I don't think it's always practical or desired to move the hotkey support completely out of the program itself. Most users (especially consumer/nontechnical people such as many OBS users) are not willing to setup hotkeys through a third-party program to manually get it to control OBS externally... so I think it needs to support hotkeys internally, whether there is also control possible via an external socket/dbus/etc. or not.
It's extremely user hostile.
> The problem with X11 is that it has for a long time exposed too much unrelated functionality like this to the user
It's not "unrelated functionality". It's an entirely generic ability to listen to events that is available with Wayland as well, just with an added restriction.
Sounds like a nightmare for everyone involved to me
If there was a single standard way, great. In the meantime I'll stick to X11, which isn't this incredibly user-hostile.
That doesn't really change what i said.
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.