Live data from Hacker News

I hate: Programming Wayland applications

p4m.dev

101–110 of 184 posts

Re: I hate: Programming Wayland applications

#101
post #6

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 t…

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.

Re: I hate: Programming Wayland applications

#102
post #82

Earlier quoted context omitted.

I mean specifically things that using using Wayland will improve.

The commenter above appeared to reference Wayland preventing apps from having unrestricted access to screen contents and clipboard, so those.

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. It should have been something as easy as clicking a set of windows to specify something like the first being allowed to access the others, or like each of them being able to access all the others.

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.

Re: I hate: Programming Wayland applications

#103
post #77

Earlier quoted context omitted.

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.

XCB did not largely replace Xlib. In fact, some (all?) implementations of Xlib are built on top of XCB.

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.

Re: I hate: Programming Wayland applications

#104
post #77

Earlier quoted context omitted.

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.

XCB did not largely replace Xlib. In fact, some (all?) implementations of Xlib are built on top of XCB.

Turns out you want to build higher-level interfaces on top of lower-level interfaces, not the other way around.

Re: I hate: Programming Wayland applications

#105
post #77

Earlier quoted context omitted.

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). https://www.phoronix.com/news/Vulkan-Joy-To-Use-2025

That's good to hear!

Re: I hate: Programming Wayland applications

#106
post #49

Earlier quoted context omitted.

Especially systemd. Declarative management of services is a bad thing? Some people just wanna complain

That is a strawman. That is not the aspect of systemd people object to.

That's fair. I have not interacted with it beyond using journalctl to debug various services and I found it easy to work with

Re: I hate: Programming Wayland applications

#107
post #64

Earlier quoted context omitted.

Especially systemd. Declarative management of services is a bad thing? Some people just wanna complain

There are ~three groups in the systemd debate. 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 w…

You're right I do fall into category 1

Re: I hate: Programming Wayland applications

#108
post #8

Earlier quoted context omitted.

It is a damn shame that tools like xdotool (automation) and sxhkd (global keybinds) are impossible to recreate under Wayland.

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.

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.

Re: I hate: Programming Wayland applications

#109
post #99

Earlier quoted context omitted.

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, d…

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.

Re: I hate: Programming Wayland applications

#110
post #66

Earlier quoted context omitted.

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…

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…

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

Post reply on HN