[Blackthorn]

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

[seba_dos1]

xdg-shell is an optional extension for a compositor and yet you can reliably deploy things that depend on it. You're barking at the wrong tree.

[MarsIronPI]

OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?

[seba_dos1]

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.

[incrudible]

You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.

[seba_dos1]

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

[Brian_K_White]

You did not. You dismissed something, but not effectively.

[braiamp]

Why should a display manager concern itself with routing keystrokes to every application.

[MarsIronPI]

Why should a display manager also have to implement window management? (I know this is a separate complaint, but I still think it's a valid one.)