autokey-gtk phrases with "Paste using: Mouse Selection" don't expand

[ronjouch]

Classification:

Bug

Reproducibility:

Always

Summary

Removal of the trigger characters does happen, but then no phrase is inserted

Steps to Reproduce

• Create a phrase with Paste using "Mouse Selection" phrase expanding ttt to testphrase,
• Type ttt

Expected Results

• Trigger ttt is removed.
• testphrase is inserted.

Actual Results

• Trigger ttt is removed (with 3 BACKSPACE, see log)...
• ... but testphrase is not inserted.

autokey-gtk --verbose output:

2018-06-06 13:16:04,390 DEBUG - iomediator - Send via clipboard
2018-06-06 13:16:04,390 DEBUG - service - Input stack at end of handle_keypress: deque([], maxlen=150)
2018-06-06 13:16:04,391 ERROR - service - Ignored locking error in handle_keypress
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/autokey/service.py", line 210, in __tryReleaseLock
    self.configManager.lock.release()
RuntimeError: release unlocked lock
2018-06-06 13:16:04,393 DEBUG - interface - Send special key: [<Key.BACKSPACE: '<backspace>'>]
2018-06-06 13:16:04,396 DEBUG - interface - Send special key: [<Key.BACKSPACE: '<backspace>'>]
2018-06-06 13:16:04,398 DEBUG - interface - Send special key: [<Key.BACKSPACE: '<backspace>'>]
2018-06-06 13:16:04,401 DEBUG - interface - Sending string: 'testphrase'
2018-06-06 13:16:04,406 DEBUG - interface - Send via clipboard done
2018-06-06 13:16:04,418 DEBUG - service - Received mouse click - resetting buffer

Version

AutoKey-Py3 > 0.94.1 on master with 572316b , on

• Arch via AUR
• Ubuntu via PPA

Distro:

Notes

Followup of 572316b#commitcomment-29270271 , which succeeds at preventing a crash, but fails at doing the phrase replacement.

Workaround: use other replacement methods (clipboard / keyboard)

[luziferius]

Now I got how it works, so all I can say is: Works for me…
(Not given) explanation of this feature: AutoKey sends via mouse selection by using the default paste action for the mouse clipboard, which is pressing the middle mouse button (or mouse wheel).

This activates the window currently below the mouse cursor and/or places the text cursor directly under the mouse cursor, then pastes there.
This causes the pasted phrase to end up wherever the mouse cursor currently points to… If this happens to be some non-text-editor widget, the phrase appears to be lost.

#153 still applies for both clipboard methods.

[ronjouch]

This activates the window currently below the mouse cursor and/or places the text cursor directly under the mouse cursor, then pastes there. This causes the pasted phrase to end up wherever the mouse cursor currently points to… If this happens to be some non-text-editor widget, the phrase appears to be lost.

Indeed :-/ , even when the cursor is over a terminal (tested with Gnome Terminal). Back to Keyboard with bug #151, or Clipboard with bug #153.

[luziferius]

I’ve refactored the pasting, so mouse selection should always expand and then restore the previous content.
Since the mouse selection method is rather quirky at best by design, I’ll close this as fixed.

To work reliably, autokey has to move the mouse cursor to the desired location before pasting.

Moving the cursor is easy and possible from within current AutoKey, but finding the exact spot where to paste is far from easy. This requires analysing the screen content, find the currently active text widget (think of 'light theme', 'dark theme', each computer game looking different) and then find the text cursor (which might be invisible!).
E.g. Sauerbraten/Cube2 has a UI that is freely floating inside the 3D game space at almost arbitrary angles…

[ronjouch]

@luziferius 👍, makes total sense; maybe the mouse selection method should be removed, then. Anyway, as usual, thanks for the followup, and I'll test the fix for #153 soon.