5 ms·

This is absurd. Author claims that "Wayland breaks automation software". They then use the "py37-autokey" tool as an example. Autokey uses Xorg APIs for key ha

by dbrgn 6y ago

This is absurd. Author claims that "Wayland breaks automation software". They then use the "py37-autokey" tool as an example. Autokey uses Xorg APIs for key handling. Of course this is not going to work on Wayland since it's written for Xorg and not for Wayland. The author is probably the type of person that buys an AMD graphics card, and then complains that AMD "breaks" software that's based on CUDA...

edflsafoiewq 6y ago
Is py37-autokey-for-Wayland possible?
- arghwhat 6y ago
  Yes, officially and well contained mechanisms exist (used for virtual keyboards). Heck, you can even go a layer lower and simulate a keyboard event device, which would work with any window system, past, present and future. Even kmscon.
- deleted 6y ago
  [deleted]
Hitton 6y ago
That was just example. Because of Wayland's security model of sandboxing applications, none such tool will work. Currently afaik only way to do something similar is using /dev/uinput as does for instance ydotool, but its capabilities are vastly inferior.
- ddevault 6y ago
  What makes you think uinput is less capable? Ultimately everything that uses input uses uinput, it's the source of truth.
  - adrusi 6y ago
    For the same reason that it can make sense to say that python is more powerful than C, even though you can obviously do more things with C than with python. Xdotool lets you send keystrokes to a particular window, even if it's not in focus. You can do that with ydotool if you also do some sway IPC, but it's not as convenient, and no one has made a higher-level tool, possibly because it would be a nightmare to make it work with multiple different compositors. Do you know if there's any standardization effort to support xdotool-like functionality over wayland with some kind of actual security model (using ydotool kind of subverts the security improvements wayland offers unless one does more due diligence than is pleasant to do for quick scripts)
    - ddevault 6y ago
      I see your point. No, I'm not familiar with such an effort, though it could probably be incorporated into our existing protocols, perhaps with only minor changes.
    - dashboardmess 6y ago
      Actually, xdotool is the wrong place for this kind of automation. IMO, the optimal place to implement this is in the toolkits, to make it possible to read text and properly click buttons and menus.
ddevault 6y ago
This list is so full of utter bullshit. I am so sick of this nonsense. Some more examples: > Wayland breaks screen sharing applications > https://github.com/jitsi/jitsi-meet/issues/6389 https://github.com/jitsi/jitsi-meet/issues/6389 x broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted. It's not Jitsi's freaking problem! JavaScript webshit doesn't speak Wayalnd or X. This should be implemented in the web browser, and, surprise - it already has been done for Wayland and shipped in Firefox and Chromium. I'm not going to break down all of these, but it's just a bunch of vile horseshit. And you know what? I'm tired of debunking this crap. "Wayland devs break things and make everyone else deal with it." Xorg is broken and all of the user applications expect us to just volunteer to maintain a broken piece of shit forever. No matter how you slice it, someone's gonna have to do it, and there's plenty of shit that's permanently broken on X11 which works fine on Wayland, too. Fuck me, I'm so sick of this shit. My new answer to "I don't like Wayland" is "I don't like you." I'm tired of using reason. These people are like fucking flat earthers.
swiley 6y ago
Automation software like that will never work on wayland (certainly not across different compositors) since it violates the security model.
- kevincox 6y ago
  That's not true. It bypasses the default security model but it is entirely possible (and to be honest I'm surprised there hasn't been progress) for the user (or the compositor automatically) to provide an API that provides the required access to whitelisted applications. It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.
kevincox 6y ago
I think you have a point, and I agree about this kind of complaint for screencapture where there are APIs on Wayland so you can't point at X-based software that didn't port and say "it's broken"! However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor. I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.

by dbrgn 6y ago

edflsafoiewq 6y ago

Is py37-autokey-for-Wayland possible?

arghwhat 6y ago
Yes, officially and well contained mechanisms exist (used for virtual keyboards). Heck, you can even go a layer lower and simulate a keyboard event device, which would work with any window system, past, present and future. Even kmscon.
deleted 6y ago
[deleted]

Hitton 6y ago

That was just example. Because of Wayland's security model of sandboxing applications, none such tool will work. Currently afaik only way to do something similar is using /dev/uinput as does for instance ydotool, but its capabilities are vastly inferior.

ddevault 6y ago
What makes you think uinput is less capable? Ultimately everything that uses input uses uinput, it's the source of truth.
- adrusi 6y ago
  For the same reason that it can make sense to say that python is more powerful than C, even though you can obviously do more things with C than with python. Xdotool lets you send keystrokes to a particular window, even if it's not in focus. You can do that with ydotool if you also do some sway IPC, but it's not as convenient, and no one has made a higher-level tool, possibly because it would be a nightmare to make it work with multiple different compositors. Do you know if there's any standardization effort to support xdotool-like functionality over wayland with some kind of actual security model (using ydotool kind of subverts the security improvements wayland offers unless one does more due diligence than is pleasant to do for quick scripts)
  - ddevault 6y ago
    I see your point. No, I'm not familiar with such an effort, though it could probably be incorporated into our existing protocols, perhaps with only minor changes.
  - dashboardmess 6y ago
    Actually, xdotool is the wrong place for this kind of automation. IMO, the optimal place to implement this is in the toolkits, to make it possible to read text and properly click buttons and menus.

ddevault 6y ago

This list is so full of utter bullshit. I am so sick of this nonsense. Some more examples: > Wayland breaks screen sharing applications > https://github.com/jitsi/jitsi-meet/issues/6389 https://github.com/jitsi/jitsi-meet/issues/6389 x broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted. It's not Jitsi's freaking problem! JavaScript webshit doesn't speak Wayalnd or X. This should be implemented in the web browser, and, surprise - it already has been done for Wayland and shipped in Firefox and Chromium. I'm not going to break down all of these, but it's just a bunch of vile horseshit. And you know what? I'm tired of debunking this crap. "Wayland devs break things and make everyone else deal with it." Xorg is broken and all of the user applications expect us to just volunteer to maintain a broken piece of shit forever. No matter how you slice it, someone's gonna have to do it, and there's plenty of shit that's permanently broken on X11 which works fine on Wayland, too. Fuck me, I'm so sick of this shit. My new answer to "I don't like Wayland" is "I don't like you." I'm tired of using reason. These people are like fucking flat earthers.

swiley 6y ago

Automation software like that will never work on wayland (certainly not across different compositors) since it violates the security model.

kevincox 6y ago
That's not true. It bypasses the default security model but it is entirely possible (and to be honest I'm surprised there hasn't been progress) for the user (or the compositor automatically) to provide an API that provides the required access to whitelisted applications. It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.

kevincox 6y ago

I think you have a point, and I agree about this kind of complaint for screencapture where there are APIs on Wayland so you can't point at X-based software that didn't port and say "it's broken"! However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor. I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.