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.
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.
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.
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.
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)
The whining about Wayland an systemd is perfectly justified because unlike other open-source applications they are not chosen freely by the user.
For other open-source applications, if you do not like them you do not install them and you choose something else. There is no reason for any complaint.
On the other hand, you may have used some Linux distribution for a decade and then someone forces upon you systemd and/or Wayland, regardless whether you want them or not.
In such cases it is very reasonable to complain about this, because whoever has chosen systemd and Wayland now forces you to do a lot of unnecessary work, either by changing your workflow to accommodate them or by switching to another distribution, which also requires a new workflow.
I have not switched to either systemd or Wayland, because I have never seen anyone capable to explain even a single advantage of them over what I am using.
I have tested once systemd, by installing Arch and using it for a month, but I have found a bug so ugly that my opinion about the technical competence of the systemd designers has dropped so low that I have never tried it again.
I am using Gentoo, which unlike other distributions does not yet force the choices of the maintainers upon the users, so I can still choose to not use either systemd or Wayland. However, I am worried about the future because both of them continue to invade other software packages, so even without using the complete systemd you may need to use some parts extracted from it, because other traditional packages have been substituted with packages that depend somehow on systemd.
Eventually, it is likely that I would have to write myself replacements for those packages, to expel completely systemd, but I hate to do such unnecessary work when I was happy with the older packages, which worked perfectly fine and they needed no replacement.
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...
I wouldn't call wayland-client a callback hell. All callbacks are called at expected time when you call wl_display_dispatch() (and its variants) or during wl_display_roundtrip(). GLFW also works with callbacks and nobody complains about that.
There is no async involved so function coloring argument doesn't really apply here.
I don't share author's hate for them, but they are definitely more verbose than popping form event queue and switch statement on event type ala SDL loop. Plenty of callbacks just set parameters in some state struct and do not propagate further. And you need to fill the vtable structs, and register that as listener. This boilerplate is probably the reason why basic window examples have ~200 lines instead of 40. But in larger project this is barely a problem.
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.
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 the low level details tend to change over time and then it's too late and you're committed to supporting something that doesn't make sense anymore. like branch delay slots in some RISC cpus, or vulkan (https://www.sebastianaaltonen.com/blog/no-graphics-api)
Wayland makes it unnecessarily difficult to make simple clients. Gnome still doesn't support server-side window decoration and libdecor is an absolute nightmare and wayland-cursor doesn't even detect the system theme properly.
>and I still don't know what's the difference between them (wl_display_roundtrip() & wl_display_dispatch()) and in what order to call them on
I've been struggling with this initially as well, it's pretty poorly explained in docs. Short explanation:
Wayland-client library implements a queues over the socket. So to get it, you have to think about when is the socket read from and written to, and when are the queues pulled from or pushed to.
There is always a default queue, but for example EGL+OpenGL creates it's own queue, which further makes it more confusing.
- `wl_display_dispatch_pending()` only pulls messages from default queue to callbacks
- `wl_display_dispatch()` also tries to do blocking read on the socket if no messages are in queue
- quite recently `wl_display_dispatch_queue_timeout()` was finally added, so you can do non-blocking read from the socket. earlier you had to hack the function yourself
- `wl_display_flush()` writes enqueued messages in queue to socket
- `wl_display_roundtrip()` sends a ping message and does blocking wait for response. the purpose is that you also send all enqueued requests and receive and process all responses. for example during init you call it to create registry and enumerate the objects, and you call it for second time to enumerate further protocol objects that got registered in registry callback, such as seat
- `eglSwapBuffers()` operates on its own queue, but reading from socket also enqueues to default queue, so you should always call `wl_display_dispatch_pending()` (on default queue) afterwards
There is also a way to get around being stuck in `eglSwapBuffers()` during window inhibition: disable the blocking with `eglSwapInterval(0)` and use `wl_surface_frame()` callback, and you get notified in callback when you can redraw and swap again. But you can't do blocking reads with `wl_display_dispatch()` anymore, have to use the timeout variant.
After using it this way, you can also easily manage multiple vsynced windows independently on the same thread, and even use wayland socket in epoll event loop. None of this is documented of course.
The clipboard interface is definitely compromised a bit by being shared with drag-and-drop events, but it's not that complicated. Also there is a pitfall when you copy-paste to your own application and don't use any async event loop, you can get deadlocked by being expected to write and read on the same file descriptor at the same time.
I'd like to see some code to understand what it takes to write a functioning Wayland application, a bit like David Rosenthal did in his paper "A Simple X11 Client Program -or- How hard can it really be to write ‘Hello, World’?" (USENIX 1988 Winter Proceedings).
Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it.
Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.
29 comments
[ 3.2 ms ] story [ 49.7 ms ] threadSo 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.
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.
https://www.youtube.com/watch?v=HMKaM3FdsgY
It's getting a bit boring, especially since none really does more than complain.
For other open-source applications, if you do not like them you do not install them and you choose something else. There is no reason for any complaint.
On the other hand, you may have used some Linux distribution for a decade and then someone forces upon you systemd and/or Wayland, regardless whether you want them or not.
In such cases it is very reasonable to complain about this, because whoever has chosen systemd and Wayland now forces you to do a lot of unnecessary work, either by changing your workflow to accommodate them or by switching to another distribution, which also requires a new workflow.
I have not switched to either systemd or Wayland, because I have never seen anyone capable to explain even a single advantage of them over what I am using.
I have tested once systemd, by installing Arch and using it for a month, but I have found a bug so ugly that my opinion about the technical competence of the systemd designers has dropped so low that I have never tried it again.
I am using Gentoo, which unlike other distributions does not yet force the choices of the maintainers upon the users, so I can still choose to not use either systemd or Wayland. However, I am worried about the future because both of them continue to invade other software packages, so even without using the complete systemd you may need to use some parts extracted from it, because other traditional packages have been substituted with packages that depend somehow on systemd.
Eventually, it is likely that I would have to write myself replacements for those packages, to expel completely systemd, but I hate to do such unnecessary work when I was happy with the older packages, which worked perfectly fine and they needed no replacement.
There is no async involved so function coloring argument doesn't really apply here.
I don't share author's hate for them, but they are definitely more verbose than popping form event queue and switch statement on event type ala SDL loop. Plenty of callbacks just set parameters in some state struct and do not propagate further. And you need to fill the vtable structs, and register that as listener. This boilerplate is probably the reason why basic window examples have ~200 lines instead of 40. But in larger project this is barely a problem.
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.
It satisfies the requirement to "make easy things easy, make hard things doable" and it also gets you cross platform support.
> 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.)
Do people recommend the API surface should be totally flat and the same for all developers?
I've been struggling with this initially as well, it's pretty poorly explained in docs. Short explanation:
Wayland-client library implements a queues over the socket. So to get it, you have to think about when is the socket read from and written to, and when are the queues pulled from or pushed to. There is always a default queue, but for example EGL+OpenGL creates it's own queue, which further makes it more confusing.
- `wl_display_dispatch_pending()` only pulls messages from default queue to callbacks
- `wl_display_dispatch()` also tries to do blocking read on the socket if no messages are in queue
- quite recently `wl_display_dispatch_queue_timeout()` was finally added, so you can do non-blocking read from the socket. earlier you had to hack the function yourself
- `wl_display_flush()` writes enqueued messages in queue to socket
- `wl_display_roundtrip()` sends a ping message and does blocking wait for response. the purpose is that you also send all enqueued requests and receive and process all responses. for example during init you call it to create registry and enumerate the objects, and you call it for second time to enumerate further protocol objects that got registered in registry callback, such as seat
- `eglSwapBuffers()` operates on its own queue, but reading from socket also enqueues to default queue, so you should always call `wl_display_dispatch_pending()` (on default queue) afterwards
There is also a way to get around being stuck in `eglSwapBuffers()` during window inhibition: disable the blocking with `eglSwapInterval(0)` and use `wl_surface_frame()` callback, and you get notified in callback when you can redraw and swap again. But you can't do blocking reads with `wl_display_dispatch()` anymore, have to use the timeout variant. After using it this way, you can also easily manage multiple vsynced windows independently on the same thread, and even use wayland socket in epoll event loop. None of this is documented of course.
The clipboard interface is definitely compromised a bit by being shared with drag-and-drop events, but it's not that complicated. Also there is a pitfall when you copy-paste to your own application and don't use any async event loop, you can get deadlocked by being expected to write and read on the same file descriptor at the same time.
The API feels like a hardcore OOP/C++ developer's first C interface.
No you don't need to reinvent the wheel thank you.
Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it. Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.