| ▲ | craftkiller 16 hours 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 |
|
| ▲ | Blackthorn 16 hours ago | parent | next [-] |
| > 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 16 hours ago | parent [-] | | 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 15 hours ago | parent [-] | | OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations? | | |
| ▲ | seba_dos1 15 hours ago | parent [-] | | 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 12 hours ago | parent [-] | | You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern. | | |
| ▲ | seba_dos1 9 hours ago | parent | next [-] | | 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). | |
| ▲ | braiamp 9 hours ago | parent | prev [-] | | Why should a display manager concern itself with routing keystrokes to every application. | | |
| ▲ | MarsIronPI 8 hours ago | parent [-] | | 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.) |
|
|
|
|
|
|
|
| ▲ | diath 16 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | lelanthran 15 hours ago | parent | prev [-] |
| > 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. |
| |
| ▲ | craftkiller 10 hours ago | parent [-] | | 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. |
|
