5 ms·

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

j16sdiz 6mo ago
Not literally impossible. You just need to write your own composer!
Krutonium 6mo ago
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.
craftkiller 6mo 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 https://wayland.app/protocols/hyprland-global-shortcuts-v1
- diath 6mo ago
  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.
  - vasvir 6mo ago
    like the web and we saw how that went... Oh wait!
    - Brian_K_White 6mo ago
      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.
- Blackthorn 6mo ago
  > 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 6mo ago
    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 6mo ago
      OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?
      - seba_dos1 6mo ago
        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 6mo ago
        You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.
        seba_dos1 6mo ago
        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).
- lelanthran 6mo ago
  > 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 6mo ago
    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/ https://isaacfreund.com/blog/river-window-management/ . If they're successful we might see that protocol adopted by the other compositors.
flexagoon 6mo ago
ydotool exists https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool
- dzogchen 6mo ago
  The name is pretty similar, but looks like there is where the similarities end.
James_K 6mo ago
I'm using Sway right now and I have key binds. Not sure why you think that's impossible.
- vidarh 6mo ago
  Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.
  - James_K 6mo ago
    How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
    - lelanthran 6mo ago
      > Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off. Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things. Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
    - vidarh 6mo ago
      There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything. This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.
    - ranger_danger 6mo ago
zwarag 6mo ago
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.

j16sdiz 6mo ago

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

Krutonium 6mo ago

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.

craftkiller 6mo 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 https://wayland.app/protocols/hyprland-global-shortcuts-v1

diath 6mo ago
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.
- vasvir 6mo ago
  like the web and we saw how that went... Oh wait!
  - Brian_K_White 6mo ago
    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.
Blackthorn 6mo ago
> 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 6mo ago
  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 6mo ago
    OK so why wasn't this implemented in the first place? For that matter, why does our reinvented wheel have fundamental limitations?
    - seba_dos1 6mo ago
      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 6mo ago
        You can’t effectively dismiss a critique of something missing from the core protocol by declaring it to not be its concern.
        seba_dos1 6mo ago
        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).
lelanthran 6mo ago
> 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 6mo ago
  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/ https://isaacfreund.com/blog/river-window-management/ . If they're successful we might see that protocol adopted by the other compositors.

flexagoon 6mo ago

ydotool exists https://github.com/ReimuNotMoe/ydotool https://github.com/ReimuNotMoe/ydotool

dzogchen 6mo ago
The name is pretty similar, but looks like there is where the similarities end.

James_K 6mo ago

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

vidarh 6mo ago
Th point is the decoupling. sxkhd runs irrespective of wm and means your en can optionally choose not to handle key bindings at all. With Wayland you end up depending on whether or not and how your compositor supports it.
- James_K 6mo ago
  How many keybings do you have and how often do you try new window managers? Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off.
  - lelanthran 6mo ago
    > Compromising the security of the whole system just to save you a few `sed`s when writing some config files seems like a bad trade off. Those aren't the only two options. There's no need to compromise the entire system for everybody if the Wayland devs would agree to configuration that controls these things. Then those of us who need stuff to work rgardless of WM would get stuff to work and the rest of the Wayland users can simply go with a WM that suits them.
  - vidarh 6mo ago
    There's no need to compromise the security of the whole system. A trivially safe option would have been to restrict the ability to acquire global keybindings to specific clients, and require the user to confirm either once or every time (or any other policy you'd prefer). An X server could do that without breaking anything. This issue is typical of the thinking that went into Wayland: No consideration was made when Wayland was announced of the fact that there were far simpler ways of achieving the same level of security.
  - ranger_danger 6mo ago

zwarag 6mo ago

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.