Skip to content
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

Draft
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

sebastiansam55
Copy link
Contributor

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 the lib directory in the terminal and launch via python3 -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
Screenshot from 2021-08-24 07-28-04

The change uses python's time.sleep() method and is only activated when type_delay is greater than or equal to 0.

If someone can confirm this fix I can;

  • add this to the UI
  • add it for abbreviation triggers for scripts
  • Add a keyboard module method

@josephj11
Copy link
Contributor

Nice. Looking forward to seeing if this addresses some of the other issues we are seeing.

@BlueDrink9
Copy link
Collaborator

BlueDrink9 commented Aug 25, 2021

Very good. Do you think it would be too difficult to make this a per-phrase option rather than global? EDIT: Nvm, my apologies it is per-phrase.

@sebastiansam55
Copy link
Contributor Author

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 set_string arguments it defaults to 0 in the arguments for the function so when something calls it that doesn't include the variable it skips the time.sleep.

Copy link
Collaborator

@BlueDrink9 BlueDrink9 left a 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

@@ -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()
Copy link
Collaborator

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)

Copy link
Collaborator

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)
Copy link
Collaborator

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

@@ -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
Copy link
Collaborator

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)

@BlueDrink9
Copy link
Collaborator

As a side note, if you rebase on develop and push again the tests should be fixed.

@josephj11
Copy link
Contributor

This looks like a step in the right direction. The function that @bjohas enhanced in #566 has three separate optional delay parameters, so I'm not sure if reducing it to just one will cover all cases.

@BlueDrink9
Copy link
Collaborator

Also, if you add this to a gui don't forget to also add it to engine.create_phrase in the scripting api if appropriate.

(Also update changelog)

@bjohas
Copy link

bjohas commented Aug 30, 2021

This looks like a step in the right direction. The function that @bjohas enhanced in #566 has three separate optional delay parameters, so I'm not sure if reducing it to just one will cover all cases.

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.

@@ -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:
Copy link
Collaborator

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?

@BlueDrink9
Copy link
Collaborator

I have just rebased this against the newly-refactored develop. I suggest you reset --hard to https://github.com/BlueDrink9/autokey/tree/sebastiansam55-develop-slowtypemethod

@allanlaal
Copy link

allanlaal commented Dec 26, 2021

@sebastiansam55 just tried branch develop-slowtypemethod tip. seems to work ok with medium load and loooong urls :)

altough Quit will remove "type_delay from autokey.json

@allanlaal
Copy link

allanlaal commented Dec 26, 2021

I set "type_delay": 0.001

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 : / ? = & (shift + numrow keys on my estonian layout):
httpsxgis.maaamet.eemapsisappid82useridat11620958zlevel10,549052.10876467,6546996.6812135setlegend1821

Expected:
https://xgis.maaamet.ee/maps/XGis?app_id=UU82A&user_id=at&LANG=1&WIDTH=1620&HEIGHT=958&zlevel=10,549052.10876467,6546996.6812135&setlegend=UUKAT1_82=1

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)
this workaround is by definition so slow that with longer autocompletes I might aswell go make coffee while I wait, which kinda negates the point of using text files to copypaste stuff from vs Autokey. has there been any other alternatives to slow typing? I tend to use my computer at its limit and other apps need 10x more load to start acting weird :|

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants