tap , double tap , hold key #731

ZeRenCZ · 2022-09-11T15:00:28Z

ZeRenCZ
Sep 11, 2022

hi, is it possible to make script like this?

if single tap key('a')
    keyboard.send_key('B')
else if double tap key('a')
   keyboard.send_key('C')
else if hold key('a')
   keyboard.send_key('D')

Answered by ZeRenCZ

Sep 17, 2022

I will give it a try

thx for your answers

View full answer

josephj11 · 2022-09-11T20:52:34Z

josephj11
Sep 11, 2022
Maintainer

Welcome to AutoKey.

Sort of...

TL;DR: Most of this is uncharted territory and would require significant experimentation.

Let's break this down. (Thinking out loud ...)

To get it out if the way first, read this and don't use keyboard.send_key() unless nothing else works.

There are no API calls, etc. that do exactly what you want, so you have to try to work around it.

I don't want to just say, "no", because our scripts are coded in native Python, so if you're skilled enough, you can do almost anything.

You could write a script that uses an AutoKey stored variables to count how many times it has been called and how long ago the last call was. This would allow you to detect multiple taps of a hotkey and differentiate between two taps that were pressed close together in time. That solves one problem, but creates another one - acting on a single tap is now hard.

You could have your script trigger on the first hotkey keypress, and then call wait for keypress after checking the time. When it returns (there's no return code), you could check the time again. If the elapsed time is shorter than how long you told it to wait for the same keypress, then you got one. If the elapsed time is also short enough for your definition of a double tap, then you'd have a double tap. But this won't easily work directly because the second tap of the same hotkey will launch a new instance of your script and that makes things rather convoluted. I don't know what the first script instance would see.

I don't immediately see any way to directly detect press and hold, but if your keyboard is setup for autorepeat when a key is held down long enough (it's a common setting), you would actually have multiple keypresses occurring at a rapid rate (determined by the keyboard key repeat parameters). You could detect this as above, but you could end up with a lot of instances of your script running simultaneously which might get AutoKey upset. It's multi-threaded, so it can do that, but I don't have a lot of confidence in it if you stress it. We don't have much experience with multi-threaded use cases, so there may be bugs.

To avoid some of this, you might have to use one hotkey to enter "multipress detection" mode and have your script look for multiple presses of another key that is not a hotkey.

All of these approaches come with housekeeping overhead of setting up initial conditions and then resetting them once the event has been successfully or unsuccessfully completed.

You would probably get more feedback/support for a question like this on Gitter where our developer(s) and advanced users hang out.

0 replies

Elliria · 2022-09-12T22:28:57Z

Elliria
Sep 12, 2022

AutoKey is part of the way to getting you there, but not quite:

The AutoKey API offers the keyboard.wait_for_keypress function, but it doesn't provide a return code, so you can't currently test for its event in a conditional statement. There's an open enhancement issue for it here.

Also, the AutoKey API doesn't currently offer a keyboard.wait_for_keyrelease function, which could also be useful as part of responding to key-presses. There's an open enhancement issue for that here.

Last, but not least, Joe made an excellent point that pressing the trigger key would retrigger the script, so you'd probably want to use a different key as the trigger for a script that listens for specific key-presses with some Python or Bash code.

0 replies

ZeRenCZ · 2022-09-14T17:26:11Z

ZeRenCZ
Sep 14, 2022
Author

I did find script for autohotkey, so I hoped something like that could work for Autokey

unfortunately I am not coder, I can only handle simple bash script, so I was thinking, when you create script you click
on 'set' button to make shortcut, could there be a choice 'single click' and 'double click' so I would create two scripts?

1 reply

josephj11 Sep 16, 2022
Maintainer

I mentioned this to our current lead developer on Gitter. He suggested something that might work. It still involves scripting.

It would be a single script that gets called whenever you press its hotkey.
The logic required isn't complex, but it's too hard to do in English, so I wrote some pseudocode.
This took a while to do and is probably mostly correct, but it's just pseudocode and completely untested.

Again, if you transfer this discussion to Gitter, you may find additional support. There are several other advanced users there (who usually don't read issues on GitHub) who might be interested in helping you implement this.
Since you do not consider yourself a programmer, this would probably not be the best first project to attempt. It's of low-intermediate difficulty.

That being said, rudimentary Python for something like this isn't much different than scripting in bash. If you can survive in bash, you could survive in Python. You don't need any of the advanced features of Python that are harder to master.

My personal opinion:
This could be converted to a valid enhancement issue.
However, I don't know that others would support it because

It's a very specialized niche request
It would add complication to our user interface

Also, even if supported, we currently have only one developer who has very little time for AutoKey, so this might take forever to get implemented.

ZeRenCZ · 2022-09-17T05:08:45Z

ZeRenCZ
Sep 17, 2022
Author

I will give it a try

thx for your answers

0 replies

Elliria · 2022-09-17T16:52:32Z

Elliria
Sep 17, 2022

I gave it a serious try the other night for a couple of hours and had high hopes for the conditional statements I was throwing around, but I ended up getting nowhere fast. It could be done with external libraries that don't ship with Python by default and have to be installed (like pygame or pynput, etc., with some examples of that here), but I haven't yet figured out a way to do it without adding any libraries, which would be ideal.

0 replies

josephj11 · 2022-09-17T18:44:22Z

josephj11
Sep 17, 2022
Maintainer

@Elliria I didn't try converting my pseudocode into Python (yet). Did you try something like what I suggested? What can't you do without additional capabilities (modules)? I didn't seem to need any, but since I don't have working code, I don't know if I missed anything.

0 replies

Elliria · 2022-09-18T15:13:47Z

Elliria
Sep 18, 2022

It's a mess. Do not try this at home.

I tried several variants of something like this nested if statement, which didn't even venture to deal with long-presses and only attempted to differentiate between single-presses and double-presses:

retCode = keyboard.wait_for_keypress("a",timeOut=1)
if retCode:
	if retCode:
		keyboard.send_keys("double-tapped")
else:
	keyboard.send_keys("single-tapped")

Then, I tried several variants of this nested if statement, with the idea being that if you press the "a" key once, you get an a, if you press it twice, you get aa, and if you hold it down, you get aaaaaaaaaaaa and so on, so if you can test for three or more presses, two presses, or one press of the "a" key, that should do it. It fell over because the nesting didn't count them properly:

retCode = keyboard.wait_for_keypress("a",timeOut=1)

if retCode:
	if retCode:
		if retCode:
			keyboard.send_keys("long-pressed")
			engine.run_script("foo")
elif retCode:
	if retCode:
		keyboard.send_keys("double-tapped")
		engine.run_script("foo")
elif retCode:
	keyboard.send_keys("single-tapped")
	engine.run_script("foo")
else:
	pass

It gave me output, but it didn't accurately catch all the presses of the "a" key, so this it's some seriously bad code.

In one of my experiments, I tried to get each of the conditions to update a counter variable that starts out at zero (with counter = 0) and gets one added to it (with counter += 1) each time the a key is pressed. The counter didn't update as expected. When I tried debugging it by printing the counter's value every time it was updated, it was always a mixture of either 1 or 11, which seems to be string concatenation rather than an increasing counter (this might have to do with my use of the keyboard.send_keys() function, which requires a string. My bad.

Despite that (and figuring that I'd fix that mess later), I tried combining the counter with using engine.run_script("foo") to reload the current script, but that doesn't seem to work as expected. It just loop its last output forever rather than resetting the script and waiting for the next key-press.

I also tried putting several variants of the above scripts into a function and having it call itself from within the conditions so that it would reset (and avoid the problem of not being able to get the script to reset itself) and I managed to make that fail as well.

Eventually, I suspected that going to bed would offer me a greater chance of success, so I gave that a try and it worked perfectly.

I didn't try your pseudo-code, but that's probably because by the time I looked at it, my brains were spaghetti from all that miserable messing around and I took one look at it and ran away screaming. I'll have to take another look at it, but I suspect it will look just fine other than the pesky problem of recognizing each press of the "a" key.

Last, but not least, for the heck of it, I tried several variants of this just now, also with no success, although I love how it looks and when I'm making code fall over hard, I have to get my satisfaction from somewhere:

retCode = keyboard.wait_for_keypress("a",timeOut=1)

def foobarbazbat():
	if retCode:
		if retCode:
			if retCode:
				keyboard.send_keys("long-pressed")
				return
			keyboard.send_keys("double-tapped")
			return
		keyboard.send_keys("single-tapped")
		return
foobarbazbat()

2 replies

josephj11 Sep 20, 2022
Maintainer

When dealing with things that are just Python, the interpreter is your friend.

Just tried this:

$ python3
Python 3.6.9 (default, Jun 29 2022, 11:45:57) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> counter = 0
>>> print(counter)
0
>>> counter += 1
>>> print(counter)
1
>>> counter += 1
>>> print(counter)
2
>>>

and it works as expected. Python uses dynamic typing, so a variable takes the type of the last value assigned to it. If you're getting concatenation instead of addition, you must have done something like counter = "0" which made counter a string.

I just tried to do that, but it didn't work (which is good).

>>> counter = "0"
>>> print(counter)
0
>>> counter += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int
>>>

The only way I can think of that something like this might happen would be if AutoKey stored variables are only strings. I took a glance at the code and it looks like a straight dictionary entry with no conversion. I think it will store any valid Python object.

Did you start out with something like counter = "" or counter ="0" ?

I'd have to see your actual code to figure out anything further.

As for waiting for more keypresses, that probably won't work because the keypresses you're looking for are hotkey keypresses and will probably be consumed by AutoKey. Each one will start a new instance of your script which is why the subsequent invocations should update the stored counter or do other simple things and immediately exit while the first instance keeps running (until a reasonable timeout) and then reads the counter to see what value it ended up with. You also have to make sure that the counter only gets incremented if the current invocation is close enough in time to the last keypress to be considered part of a multiple keypress. If it's not, then you have to do something different - like ignore it or reset the counter to 1, depending on how you want it to work.

If your subsequent invocations don't exit very quickly, it might be possible for race condition problems to occur. If that happened, two or more instances might be running concurrently and result in the counter getting overwritten instead of being incremented sequentially as desired. (More than one instance might retrieve the same previous value of the counter if the previous ones didn't update it before the subsequent ones read it....)

If you get a race condition, you can solve it by setting a lock. You would do that by having your script first read a local stored variable and increment it and save it back. If it was > 0, then your script would have to wait for it to be one before proceeding. If it got to 1, then it could proceed, otherwise it would keep waiting... It would then decrement the counter just before it exits after running.

This might work, but it gets hairy fast if things are happening fast enough for instances to get in a queue waiting to run. So, being very fast and exiting as soon as possible will hopefully avoid all of this.

Elliria Sep 21, 2022

Yeah, my counters normally work fine. It's the fact that the dialog requires a string that messed them up. There's not much I can do about race conditions, because introducing a delay into this would be completely unacceptable to the user who wants to be able to tap or tap-tap or hold the key without worrying that I'm requiring them to do it only in a specific way. Hopefully that won't end up being an issue.

josephj11 · 2022-09-18T22:51:07Z

josephj11
Sep 18, 2022
Maintainer

Unpacking this a bit.

Looking at the API call, I don't see anything about it returning a return code at all. That was the initial problem referenced in another enhancement issue #659. Other API calls have a "Returns" item specified, but this one does not.

Note that my pseudocode did not rely on a return code, but deduced what had occurred by comparing timestamps.

The way I did it, the initial instance would keep running until it either got what it wanted or too much time had elapsed. Subsequent invocations (from user pressed hotkey) would just increment the presses counter and exit to keep from draining resources.

I see no need for the script to be recursive because it is retriggered externally and just need to know if the current instance is the first one or not.

The Python if statement does not modify the value that it tests, so nesting identical if statements is pure overhead.

This might not be the case if the expression tested by the if command had side effects such as modifying variables or other program state factors. Intentionally using side effects like this can be quite convenient, but makes reading and debugging code a lot more difficult.

0 replies

Elliria · 2022-09-20T05:02:35Z

Elliria
Sep 20, 2022

It doesn't offer a return code, which is why someone had originally contributed a sample script using the retCode variable with a Boolean value to verify whether the wait for a key-press had fired or not. The recursion in my attempts was used to listen for successive key-presses, but yeah, it's definitely overhead and isn't fully working. In my tests, I wasn't able to update a counter variable reliably inside of the if statements because of concatenation issues that had caused the script to get all confused instead of reporting the number of key-presses.

I'll mess with your pseudo-code at some point. If I parse my ~/.local/share/autokey/autokey.log file to get the time-stamps, will that location be the same for everyone or is it dependent on which operating system and/or desktop we're each using?

0 replies

josephj11 · 2022-09-20T07:45:02Z

josephj11
Sep 20, 2022
Maintainer

You're over thinking it. Your script has to save the time it was last called in a local saved variable and compare it with the time it was called now. To do that, it has to know if this is the first time it was called which it can do by looking at the value of the presses (counter) local stored variable which will start out undefined or 1 (one), depending on how you code it.

There should be no need to reference logs or anything else outside of your script.

1 reply

Elliria Sep 21, 2022

You're absolutely right. Good heavens. I'm the type of person who, when given an entire shed full of tools to select from in order to put a nail in, will grab a whole bunch of the wrong ones instead of just grabbing the hammer. Your time-stamp approach is much simpler and less invasive since it doesn't require making trips out into the operating system. It's also less error-prone and shouldn't really be hard to write at all.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tap , double tap , hold key #731

{{title}}

Replies: 10 comments 4 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

tap , double tap , hold key #731

ZeRenCZ Sep 11, 2022

Replies: 10 comments · 4 replies

josephj11 Sep 11, 2022 Maintainer

Elliria Sep 12, 2022

ZeRenCZ Sep 14, 2022 Author

josephj11 Sep 16, 2022 Maintainer

ZeRenCZ Sep 17, 2022 Author

Elliria Sep 17, 2022

josephj11 Sep 17, 2022 Maintainer

Elliria Sep 18, 2022

josephj11 Sep 20, 2022 Maintainer

Elliria Sep 21, 2022

josephj11 Sep 18, 2022 Maintainer

Elliria Sep 20, 2022

josephj11 Sep 20, 2022 Maintainer

Elliria Sep 21, 2022

ZeRenCZ
Sep 11, 2022

Replies: 10 comments 4 replies

josephj11
Sep 11, 2022
Maintainer

Elliria
Sep 12, 2022

ZeRenCZ
Sep 14, 2022
Author

josephj11 Sep 16, 2022
Maintainer

ZeRenCZ
Sep 17, 2022
Author

Elliria
Sep 17, 2022

josephj11
Sep 17, 2022
Maintainer

Elliria
Sep 18, 2022

josephj11 Sep 20, 2022
Maintainer

josephj11
Sep 18, 2022
Maintainer

Elliria
Sep 20, 2022

josephj11
Sep 20, 2022
Maintainer