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. 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.
It's not a core protocol's concern and the fact that it's being successfully implemented proves that there are no fundamental limitations there.
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, I just did. It's just not a thing that should be there at all, and it's obvious once you take a second to look at what's actually in it and why (spoiler: there's too much in it and not much can be done about it now).
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.
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.
Currently there isn't really a "window manager" layer. Just like the automation / global hotkeys mentioned above, if you wanted a separate "window manager" your compositor would need to implement a protocol to expose window management. It looks like river is taking a stab at it with their river-window-management-v1 protocol: https://isaacfreund.com/blog/river-window-management/ . If they're successful we might see that protocol adopted by the other compositors.
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.