Hacker News

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

Not literally impossible. You just need to write your own composer!

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.

I'm using Sway right now and I have key binds. Not sure why you think that's impossible.

ydotool exists

https://github.com/ReimuNotMoe/ydotool

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.

> 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

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

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.

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.

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.

To create a simple window, no it isn't. To create a rather complex application, then yes it is, compared with using a higher-level framework.

I have written some OpenGL applications in X11, so they did not use much of X11 besides setting up windows for the OpenGL contexts, after which the rest of the programs were written using the OpenGL API.

Those applications seemed quite simple to write in comparison with what is described in the parent article, despite doing animation in real time based on the mouse and keyboard inputs.

With great power comes great responsibility :)

Indeed, this is the right approach.

Moreover, it is possible to choose as the default policy that no program may access a window that it did not open, but then there must exist a very simple method for the user to specify when access is permitted, e.g. by clicking a set of windows to grant access to them.

On my desktop computers and on most of my laptops I have never experienced tearing in X11, at least during the last 25 years, using mostly NVIDIA GPUs, but also Intel GPUs and AMD GPUs.

I have experienced tearing only once, on a laptop about 10 years ago, which used NVIDIA Optimus, i.e. an NVIDIA GPU without direct video output, which used the Intel GPU to provide outputs. NVIDIA Optimus was a known source of problems in Linux and unlike with any separate NVIDIA GPU, which always worked out-of-the-box without any problems for me, with that NVIDIA Optimus I had to fiddle with the settings for a couple of days until I solved all problems, including the tearing problem.

Perhaps Wayland never had tearing problems, but I have used X11 for several decades on a variety of desktops and laptops and tearing has almost never been a problem.

However, most of the time I have used only NVIDIA or Intel GPUs for display and it seems that most complaints about tearing have been about AMD. I have always used and I am still using AMD GPUs too, but I use those for computations, not connected to monitors, so I do not know if they could have tearing problems.

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.

Well, it allowed local users to actually use their computers for computing instead of just safely consuming "apps" -- obviously that needed to go.

Keyloggers for example.

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.

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

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.

How do you make a global hotkey in all compositors with Gtk or Qt?

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

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.

I seriously doubt spewing constant toxic bile did any of the sort.

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.

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

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.

Some people just want to live in the 80s forever.

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.

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

Systemd sucks though for good reasons.

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

Firefox Reader mode. As long as that works, as was the case on this site, I don't care how bad pages people make.