6 ms·

I hate: Programming Wayland applications

175 points by dwdz 6mo ago

deterministic 6mo ago
Wayland is such a waste of programming resources and user obstacles. No you don't need to reinvent the wheel thank you.
jmclnx 6mo ago
I can say I hate all GUI programming! Luckily, all my professional programming deals with back-end processing, so I was able to avoid GUIs :) 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.
diath 6mo ago
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.
- dzogchen 6mo ago
  It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.
  - j16sdiz 6mo ago
    Not literally impossible. You just need to write your own composer!
  - Krutonium 6mo ago
    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.
  - craftkiller 6mo ago
    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 https://wayland.app/protocols/hyprland-global-shortcuts-v1
    - diath 6mo ago
      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.
      - vasvir 6mo ago
        like the web and we saw how that went... Oh wait!
        Brian_K_White 6mo ago
        I'm not sure what point you thought you were making. The web is a complete mess. 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.
    - Blackthorn 6mo ago
      > 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.
  - flexagoon 6mo ago
    ydotool exists https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool
    - dzogchen 6mo ago
      The name is pretty similar, but looks like there is where the similarities end.
  - James_K 6mo ago
    I'm using Sway right now and I have key binds. Not sure why you think that's impossible.
    - vidarh 6mo ago
      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.
      - James_K 6mo ago
        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.
        lelanthran 6mo ago
        > 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.
        vidarh 6mo ago
        There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything. 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.
        ranger_danger 6mo ago
  - zwarag 6mo ago
    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.
- j16sdiz 6mo ago
  What make it worse: there are multiple implementation of composer, with small different in behaviour. The extra security meant many automation tasks need to be done as extensions on composer level making this even worse
- zer00eyz 6mo ago
  > how would a display server work in an ideal world When designed by committee. With conflicting interests. And Veto Powers.
- IshKebab 6mo ago
  They looked at caniuse.com and thought "I want that!"
- torginus 6mo ago
  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.
zabzonk 6mo ago
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.
- cogman10 6mo ago
  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.
  - mato 6mo ago
    I used to program pure Xlib when I was 13 or so. I don't think the then-13-year-old me would manage pure Wayland.
    - atomicnumber3 6mo ago
      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.
      - adrian_b 6mo ago
        HiDPI has always been perfectly supported by X11. 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.
Avicebron 6mo ago
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.
65a 6mo ago
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.
- eqvinox 6mo ago
  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.
  - ranger_danger 6mo ago
    With great power comes great responsibility :)
    - eqvinox 6mo ago
      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?
- calvinmorrison 6mo ago
  A security disaster? Howso?
  - m132 6mo ago
    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.
    - 6mo ago
DonHopkins 6mo ago
The Decompositing Compositors, there's nothing much anyone can do. https://www.youtube.com/watch?v=HMKaM3FdsgY https://www.youtube.com/watch?v=HMKaM3FdsgY
firtoz 6mo ago
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)
izacus 6mo ago
The constant loud bile spewing over Wayland and systemd just won't stop here, will it? It's getting a bit boring, especially since none really does more than complain.
- vatsachak 6mo ago
  Especially systemd. Declarative management of services is a bad thing? Some people just wanna complain
  - flexagoon 6mo ago
    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.
  - Gualdrapo 6mo ago
    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.
  - graemep 6mo ago
    That is a strawman. That is not the aspect of systemd people object to.
    - vatsachak 6mo ago
      That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with
  - righthand 6mo ago
    Systemd sucks though for good reasons.
  - IshKebab 6mo ago
javier2 6mo ago
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...
- ape4 6mo ago
  He complained there is no way to do the easy thing in Wayland - there is a way: Gtk and QT
  - 201984 6mo ago
    How do you make a global hotkey in all compositors with Gtk or Qt?
  - flohofwoe 6mo ago
    ...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.
- cies 6mo ago
  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.
  - IshKebab 6mo ago
    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.
  - MarsIronPI 6mo ago
    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. [0]: https://git.dec05eba.com/phoenix https://git.dec05eba.com/phoenix
toinewx 6mo ago
unreadable font
- jqbd 6mo ago
  Whole website is unreadable on mobile
  - 1313ed01 6mo ago
    Firefox Reader mode. As long as that works, as was the case on this site, I don't care how bad pages people make.
    - jqbd 6mo ago
      I switched to Brave cause switching applications caused pages to reload. I hit that on Brave too now, so might be just old phone too little RAM or sth
- MintPaw 6mo ago
  To me it looks like the default cmd.exe font that was used up until win10.
vatsachak 6mo ago
Callbacks are bad?
- cactacea 6mo ago
  Yes.
- MarsIronPI 6mo ago
  Yes. See also this article[0] for what then happens to the rest of your codebase. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- MintPaw 6mo ago
  Yes, inverting the caller/callee direction is one of the hardest control flow patterns to reason about.
- mizmar 6mo ago
  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.
m132 6mo ago
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 6mo ago
  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 6mo ago
    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.
bbor 6mo ago
Poor soul — they missed `wlroots` in their googling! You’re not supposed to be solving these issues yourself.
- 201984 6mo ago
  He's writing a client, and wlroots is a library for writing servers. It would not have helped at all.
- ceayo 6mo ago
  Poor sould -- they should have googled `wlroots` before their commenting.
motorpixel 6mo ago
Writing 1300 lines of non-cross-platform windowing code sounds like masochism. GLFW is right there.
- flohofwoe 6mo ago
  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.
James_K 6mo ago
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?
- deleted 6mo ago
  [deleted]
- flohofwoe 6mo ago
  > 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).
  - robinsonb5 6mo ago
    ...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?)
- aap_ 6mo ago
  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 https://www.sebastianaaltonen.com/blog/no-graphics-api)
breve 6mo ago
Probably best off using a UI library like Avalonia: https://avaloniaui.net/ https://avaloniaui.net/ It satisfies the requirement to "make easy things easy, make hard things doable" and it also gets you cross platform support.
fonheponho 6mo ago
I have no love lost for Wayland, but this: > 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.)
- jampekka 6mo ago
  This is quite easy and very widespread to accomplish by having helper functions for common operations.
- mizmar 6mo ago
  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.
  - tempaccountabcd 6mo ago
    [dead]
- MintPaw 6mo ago
  Yeah, obviously you have multiple levels of public interfaces, like how CreateWindow calls CreateWindowEx under the hood. Do people recommend the API surface should be totally flat and the same for all developers?
bleudeballe 6mo ago
Sure puts the Wayland in Weyland-Yutani
mizmar 6mo ago
>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.
chromadon 6mo ago
This has been my experience also. The API feels like a hardcore OOP/C++ developer's first C interface.
DVRC 6mo ago
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 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.

175 points by dwdz 6mo ago

Wayland is such a waste of programming resources and user obstacles. No you don't need to reinvent the wheel thank you.

I can say I hate all GUI programming! Luckily, all my professional programming deals with back-end processing, so I was able to avoid GUIs :) 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.

diath 6mo ago

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.

dzogchen 6mo ago
It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.
- j16sdiz 6mo ago
  Not literally impossible. You just need to write your own composer!
- Krutonium 6mo ago
  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.
- craftkiller 6mo ago
  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 https://wayland.app/protocols/hyprland-global-shortcuts-v1
  - diath 6mo ago
    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.
    - vasvir 6mo ago
      like the web and we saw how that went... Oh wait!
      - Brian_K_White 6mo ago
        I'm not sure what point you thought you were making. The web is a complete mess. 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.
  - Blackthorn 6mo ago
    > 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.
- flexagoon 6mo ago
  ydotool exists https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool
  - dzogchen 6mo ago
    The name is pretty similar, but looks like there is where the similarities end.
- James_K 6mo ago
  I'm using Sway right now and I have key binds. Not sure why you think that's impossible.
  - vidarh 6mo ago
    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.
    - James_K 6mo ago
      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.
      - lelanthran 6mo ago
        > 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.
      - vidarh 6mo ago
        There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything. 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.
      - ranger_danger 6mo ago
- zwarag 6mo ago
  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.
j16sdiz 6mo ago
What make it worse: there are multiple implementation of composer, with small different in behaviour. The extra security meant many automation tasks need to be done as extensions on composer level making this even worse
zer00eyz 6mo ago
> how would a display server work in an ideal world When designed by committee. With conflicting interests. And Veto Powers.
IshKebab 6mo ago
They looked at caniuse.com and thought "I want that!"
torginus 6mo ago
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.

zabzonk 6mo ago

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.

cogman10 6mo ago
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.
- mato 6mo ago
  I used to program pure Xlib when I was 13 or so. I don't think the then-13-year-old me would manage pure Wayland.
  - atomicnumber3 6mo ago
    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.
    - adrian_b 6mo ago
      HiDPI has always been perfectly supported by X11. 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.

Avicebron 6mo ago

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.

65a 6mo ago

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.

eqvinox 6mo ago
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.
- ranger_danger 6mo ago
  With great power comes great responsibility :)
  - eqvinox 6mo ago
    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?
calvinmorrison 6mo ago
A security disaster? Howso?
- m132 6mo ago
  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.
  - 6mo ago

DonHopkins 6mo ago

The Decompositing Compositors, there's nothing much anyone can do. https://www.youtube.com/watch?v=HMKaM3FdsgY https://www.youtube.com/watch?v=HMKaM3FdsgY

firtoz 6mo ago

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)

izacus 6mo ago

The constant loud bile spewing over Wayland and systemd just won't stop here, will it? It's getting a bit boring, especially since none really does more than complain.

vatsachak 6mo ago
Especially systemd. Declarative management of services is a bad thing? Some people just wanna complain
- flexagoon 6mo ago
  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.
- Gualdrapo 6mo ago
  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.
- graemep 6mo ago
  That is a strawman. That is not the aspect of systemd people object to.
  - vatsachak 6mo ago
    That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with
- righthand 6mo ago
  Systemd sucks though for good reasons.
- IshKebab 6mo ago

javier2 6mo ago

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...

ape4 6mo ago
He complained there is no way to do the easy thing in Wayland - there is a way: Gtk and QT
- 201984 6mo ago
  How do you make a global hotkey in all compositors with Gtk or Qt?
- flohofwoe 6mo ago
  ...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.
cies 6mo ago
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.
- IshKebab 6mo ago
  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.
- MarsIronPI 6mo ago
  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. [0]: https://git.dec05eba.com/phoenix https://git.dec05eba.com/phoenix

toinewx 6mo ago

unreadable font

jqbd 6mo ago
Whole website is unreadable on mobile
- 1313ed01 6mo ago
  Firefox Reader mode. As long as that works, as was the case on this site, I don't care how bad pages people make.
  - jqbd 6mo ago
    I switched to Brave cause switching applications caused pages to reload. I hit that on Brave too now, so might be just old phone too little RAM or sth
MintPaw 6mo ago
To me it looks like the default cmd.exe font that was used up until win10.

vatsachak 6mo ago

Callbacks are bad?

cactacea 6mo ago
Yes.
MarsIronPI 6mo ago
Yes. See also this article[0] for what then happens to the rest of your codebase. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
MintPaw 6mo ago
Yes, inverting the caller/callee direction is one of the hardest control flow patterns to reason about.
mizmar 6mo ago
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.

m132 6mo ago

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 6mo ago
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 6mo ago
  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.

bbor 6mo ago

Poor soul — they missed `wlroots` in their googling! You’re not supposed to be solving these issues yourself.

201984 6mo ago
He's writing a client, and wlroots is a library for writing servers. It would not have helped at all.
ceayo 6mo ago
Poor sould -- they should have googled `wlroots` before their commenting.

motorpixel 6mo ago

Writing 1300 lines of non-cross-platform windowing code sounds like masochism. GLFW is right there.

flohofwoe 6mo ago
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.

James_K 6mo ago

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?

deleted 6mo ago
[deleted]
flohofwoe 6mo ago
> 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).
- robinsonb5 6mo ago
  ...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?)
aap_ 6mo ago
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 https://www.sebastianaaltonen.com/blog/no-graphics-api)

breve 6mo ago

Probably best off using a UI library like Avalonia: https://avaloniaui.net/ https://avaloniaui.net/ It satisfies the requirement to "make easy things easy, make hard things doable" and it also gets you cross platform support.

fonheponho 6mo ago

I have no love lost for Wayland, but this: > 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.)

jampekka 6mo ago
This is quite easy and very widespread to accomplish by having helper functions for common operations.
mizmar 6mo ago
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.
- tempaccountabcd 6mo ago
  [dead]
MintPaw 6mo ago
Yeah, obviously you have multiple levels of public interfaces, like how CreateWindow calls CreateWindowEx under the hood. Do people recommend the API surface should be totally flat and the same for all developers?

bleudeballe 6mo ago

Sure puts the Wayland in Weyland-Yutani

mizmar 6mo ago

>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.

chromadon 6mo ago

This has been my experience also. The API feels like a hardcore OOP/C++ developer's first C interface.

DVRC 6mo ago

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 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.