New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Develop slowtypemethod #596
base: develop
Are you sure you want to change the base?
Develop slowtypemethod #596
Conversation
Nice. Looking forward to seeing if this addresses some of the other issues we are seeing. |
Very good. |
Well it is per phrase, it pulls the type delay from the json file for each phrase, and phrase.py sets the default value to 0, so if one is not present it's 0. And in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The backend stuff looks great, considering the mess we are working with. I can't think of any better way to implement this
lib/autokey/interface.py
Outdated
@@ -787,6 +787,10 @@ def __sendString(self, string): | |||
self.__releaseKey(Key.SHIFT) | |||
else: | |||
logger.warning("Unable to send character %r", char) | |||
logger.info("Type delay of "+str(type_delay)) | |||
if type_delay >= 0: | |||
self.localDisplay.flush() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like that this is duplicated at iomediator.py:247.
I think it would be better to remove any mention of type_delay
from interface.py, put this 3/4 lines in a function in iomediator.py, and replace your calls to send_key
with that new function (if that makes sense)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh actually I forgot how bloated sendString is on this fork; my refactor branch tidied it up a huge amount. Leave this as-is for now, I think.
""" | ||
Sends the given number of backspace key presses. | ||
""" | ||
for i in range(count): | ||
self.interface.send_key(Key.BACKSPACE) | ||
if type_delay >= 0: | ||
time.sleep(type_delay) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See previous note about duplicating these 3 lines
lib/autokey/model/phrase.py
Outdated
@@ -84,7 +85,8 @@ def get_serializable(self): | |||
"abbreviation": AbstractAbbreviation.get_serializable(self), | |||
"hotkey": AbstractHotkey.get_serializable(self), | |||
"filter": AbstractWindowFilter.get_serializable(self), | |||
"sendMode": self.sendMode.value | |||
"sendMode": self.sendMode.value, | |||
"type_delay": self.type_delay |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If syntax permits, may as well add a comma at the end of the line to make tidier diffs for next time. (See Black for reasoning)
As a side note, if you rebase on develop and push again the tests should be fixed. |
Also, if you add this to a gui don't forget to also add it to (Also update changelog) |
I haven't experimented extensively with it, but it seems to me that the typing/deleting speed is one thing but that introducing a delay when switching from deleting to typing seems to be important. So you could be losing a lot of time introducing delays between letters, when really what you want is a delay when switching from deleting to typing. Of course - once all the delays are large enough, it doesn't matter, but I had to introduce quite significant delays between letters. Introducing a delay when switching from deleting to typing meant faster execution overall. The model I ended up with is in #566, where I actually didn't have a delay between letters at all, but just a delay when switching over. I don't know why that is, but somehow deleting and typing seem to be handled differently. Hope that helps. |
… a prexisting method
@@ -45,7 +60,7 @@ def send_keys(self, key_string, send_mode: typing.Union[ | |||
|
|||
Usage: C{keyboard.send_keys(keyString)} | |||
|
|||
@param key_string: string of keys to send. Special keys are only possible in keyboard mode. | |||
@param key_string: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What reasoning for removing this docstring?
I have just rebased this against the newly-refactored |
@sebastiansam55 just tried branch altough Quit will remove |
I set I can't remember if this has already been discovered, but it seems with superfast keyboard emulation typing there is not enough time for entering keycombo characters like Expected: the tool I use to diff the results: https://www.convertonline.io/url/diff "type_delay": 0.3 is the quickest that works for me (2.50GHz × 8 i7 at 80..150% (load: 7..14) + 32GB RAM, SSD) |
Adds the option to have a delay between sending keystrokes, as has been suggested as a solution to issues with trigger phrases not being completely removed. If we could get someone who has this problem to confirm that this would be a fix I'll work on adding the option to the Gtk UI.
Right now I have it set up to use the same delay for both the backspaces to remove a trigger word and the phrase itself.
If you want to test this you need to clone this branch
git clone https://github.com/sebastiansam55/autokey --branch develop-slowtypemethod
, go to thelib
directory in the terminal and launch viapython3 -m autokey.gtkui -lc
(Qt should reflect these changes as well). Then open the json file of the phrase that you want to type with a delay and add"type_delay": 0.1
to the end, making sure that the json is properly formatted.My config file is pictured below
The change uses python's
time.sleep()
method and is only activated whentype_delay
is greater than or equal to 0.If someone can confirm this fix I can;
keyboard
module method