No way to trigger on key release (on_release, is_pressed, is_down) #712
Comments
josephj11
added
enhancement
autokey triggers
|
While this is a valid enhancement request, there are some workarounds that may get you part way there. But first, don't run AutoKey as root! I'm not sure exactly what will happen, but at a minimum, a number of files would end up getting owned by root and that would make it unusable without root access later. Again, not sure of the details, but it's likely that your scripts would run as root, potentially allowing anyone with user access to your user scripts to insert arbitrary Python code that could be a gaping security hole. And that includes you if you make a simple mistake in your script coding. Check out this Reddit thread for some ideas of what is possible now. You still have to launch your script "normally", but once you do, you should be able to detect and act on key status changes. Also, as a general rule of thumb, it's not a good idea to write AutoKey scripts that run for a "long" time. AutoKey is multithreaded so it's possible to do, but we don't have a lot experience with those conditions and you may encounter bugs. If you would like some assistance getting this to work, come post on Gitter. And when you do succeed, we are always looking for good example code to add to our wiki. AutoKey treats a number of keys such as Shift, Ctrl, and Alt as modifier keys. It detects them, but doesn't do anything with them directly other than using them to define and detect multi-keypress hotkeys. |
RootThe main point was indeed to not run things as root even if doing so just runs it from DurationHaving a script thread sit there waiting for the key release, aka running for a "long" time, is also not ideal, though not the worst case scenario as they usually only last for a few seconds. SeparationAs mentioned, the preferred option would be to have a specific, separate script that triggers on key release. Using the There could be a tick-box or "modifier" button on the Set Hotkey dialogue box that flags it as a hotkey release trigger. But then you have to make sure your Ideally, there would be an entirely secondary script that contained the This could be either as tabs, collapsible pane or a Sub-script menu option. The tabbed editor layout would be fairly intuitive, just having 2 tabs above the script edit window. One for The collapsible pane would be below the main editing pane. Sub-script menu entry would appear when right-clicking on an existing script. When a script is selected, New > Release-script. There would be no Personally I lean towards the tab or collapsible pane option. WorkaroundsI have been poking at it a bit and have run into pynput which does not require root to run and doesn't require me to pull specific input devices as the evdev method that I had not found before. Courtesy of Nitratine, I have... this script... that does the detection (including mouse!) and it should integrate with with This is still of the "long" running script variety though, which is not ideal. |
|
Is there any chance that issue #659 could be related to this one? |
|
@Elliria I thought about that, but I think it's somewhat tangential. The OP wants things to happen when a key is already pressed or detected being released. If the key is already pressed, I don't think there will be an event to wait for. It happened before this script started. It would enable detection of a subsequent keypress, but that seems secondary to the OP. |
|
@shawarden That Python code is beyond my minimal understanding of Python. When you get things working, please tell us how you did it! |
|
Just for reference (I had to look it up): Garuda is a flavor of Arch. That's why the OP already has 0.96.0. |
|
@josephj11 I have managed to get it working but the solution is nasty. It doesn't require root though so I'll count it as a win. For this example......the application doesn't recognize the number pad's Unfortunately AutoKey's build in I have incorporated I have used AutoKey's To reliably detect the key release, I've tried to use The AutoKey script bound to NP_End:
Now to copy & past the script for numpad 2 through 0... |
|
Interesting pieces of code. Glad it works. I would have to really study it to see what it's doing. |
|
No but |
|
I went through something like that using xdotool in bash. Each browser window (possibly including a few that are never visible) counts as a separate instance. When a window isn't visible, xdotool returns -1 for the window number and you know it is one you don't need to deal with directly. Everything, tabs and even dialog boxes count as separate windows at this level. I have a bash startup script that restores my desktops the way I want them that uses xdotool to find application windows and move them to where I want them to be on my virtual desktops. |
|
It's actually quite beautiful. I'm curious why you're using an external script rather than a shared AutoKey script for releasing the key, though. I'm guessing it's because you're already out roaming around in the OS, so you may as well stay there. |
|
I've come across something sort of like that somewhat recently while doing one of a billion configurations in Kubuntu, @josephj11. I think it's a Qt thing to refer to everything as a window. When I saw it, it was something really odd like you mentioned - a button or something. Not anything one would normally consider a window. |
|
@Elliria I am trying to get something purely in AutoKey but so haven't managed to yet as AutoKey lacks the native ability to wait for a key to be released. I was originally trying to do all of this with |
|
@shawarden Some applications that use some sort of pure X interface ignore synthetic keypresses (which is what AutoKey uses). Their names usually start with an x, like xterm and xsane. Xdotool sends keypresses differently and sometimes overcomes this problem and sometimes, our fake_keypress API works. I don't understand the internals of any of it. |
|
It's incredibly frustrating.
If I running If I block the spam (by checking for a hash file My current solution, using the I don't miss Windows at all but I do miss AutoHotkey's per application hotkeys more every day and AutoKey just doesn't compare, despite using Python instead of a custom language. |
|
@shawarden If you get desperate. I'm told that a thing called Proton that works like Wine will run AHK on Linux. I usually don't mention such heretical things here, but you've obviously put in the work. As you can tell by my precision above :) I have no idea how any of that works. |
|
@josephj11 I have tried. Unfortunately Wine and Proton only let AutoHotkey see applications running in the same Wine prefix. |
|
I'm kind of surprised to see myself saying this in quite this way, but fortunately, this is a bug. The fact that AutoKey can't work with key releases is not intentional, so this should be fixed at some point. Unfortunately, those of us who have responded to this issue report so far don't have what it takes to fix it. Fortunately, there are others who also check these issue reports who just might be able to do something about it. |
|
@Elliria IMHO A bug is something that works wrong. It says a developer did something wrong or that something that used to be right no longer is and needs to be fixed for program to resume working correctly within its current scope. An oversight/omission/shortcoming is usually not a bug. So, I see this as an enhancement. I would be happy if someone implements it. By your definition, if you left out an example case on your Kdialog pages, that's a bug - even if every other presented example is perfectly correct. This almost makes all enhancement requests into bugs to be fixed. I interacted with Chris Deckter for at least a year or two before he left the project, but I have no idea what his intentions were about most things. Mainly, he went as far as he could which gave us a great project. Then, he had to support it, largely by himself, so he had limited time/energy for further enhancements. OTOH, my Duplex project (through no fault of its own) no longer works correctly with my laser printers because someone in CUPS land got clever and changed the way CUPS works with odd page count print jobs (It didn't used to do anything.). Their "enhancement" works totally backwards on my printers and makes my software fail spectacularly. Since I have absolutely no influence on anything they do in CUPS, this failure is my bug to correct. My software fails, so it's a bug - even though I didn't cause it. |
|
Sorry about that, @josephj11. I wasn't suggesting that it needed to be recategorized or that it was something other than what it is. I just meant that it's good that it's in the issue tracker, because that's where it seems like it belongs so that someone who can do something about it will be likely to find it. You're right that it would be an enhancement. We have wait_for_keypress in the API, but don't have wait_for_keyrelease yet, and that's what this issue is about, so it's a good wish. And I feel your pain with software changes causing all kinds of problems. I'm suffering with a touch of that at the moment, too, with my recent upgrade. |
Has this issue already been reported?
Is this a question rather than an issue?
What type of issue is this?
Enhancement
Which Linux distribution did you use?
Which AutoKey GUI did you use?
Qt
Which AutoKey version did you use?
How did you install AutoKey?
yay -S autokey-qtCan you briefly describe the issue?
There is no way to rigger an event/script when releasing a key without running as root.
Using the script as a user:
gives
You can run
autokey-qtas root but that's really not they way things are supposed to be done around here.Can the issue be reproduced?
Yes
What are the steps to reproduce the issue?
Require both button press events and a button release events.
Write button press event.
Bash head against trying to detect whether a key is still down or not.
What should have happened?
There should be an optional tick-box on the capture page to say this is a release trigger, or Autokey's API should come with is_pressed function to check is key is still down without being root user. Ideally the former as checking if the key is still down can cause issues with releasing and re-pressing the key.
What actually happened?
Nothing. There doesn't seem to be a sane way to trigger an event on key release.
Do you have screenshots?
no
Can you provide the output of the AutoKey command?
Anything else?
I honestly have searched but between
autohotkeyresults sneaking in andpressed,release,downandupbeing super common words, you get pages of ambiguous and unrelated junk.The debug output can see CONTROL, SHIFT and ALT key press and release events but doesn't do anything when other keys are released, only when pressed.
The text was updated successfully, but these errors were encountered: