Autokey: Qt application window focus is lost after sending keys

Update: I switched to using GNOME instead of KDE Plasma and apparently the issue doesn't present there

I can’t reproduce it on Kubuntu running KDE Frameworks 5.44.0 and Qt 5.9.5.
You haven’t specified if you use the GTK (autokey-gtk) or Qt GUI (autokey-qt).

(Starting with version 0.95.0, autokey-qt is re-written to use pure Qt5 and not use KDE libraries any more.)

My current system run KDE Frameworks 5.48.0 and Qt 5.11.1 and KDE Plasma 5.13.3. The issue happen with both autokey-gtk and autokey-qt.
However when I tried an old Manjaro distro live CD with old KDE Frameworks 5.41.0 and Qt 5.10.0 and KDE Plasma 5.11.5. The issue doesn't present.

I would guess there is some changes in either KDE Frameworks or Qt or Plasma itself that broke it.

Update: I upgraded the Manjaro distro to latest version with KDE Frameworks 5.48.0 and Qt 5.11.1 and KDE Plasma 5.13.3 and yet the problem does not happen there. Also tried Autokey on another Archlinux PC of mine and noticed the same issue. So in the end this could be distro specific.

In my case, after triggering keys sending from Autokey, Qt app window lose focus then quickly regain it for a brief split second before losing it completely. I can continue sending keys into that window with Autokey even though the focus is lost. Trying to regain window focus with mouse click within the window does not work. Instead I had to switch to another window and switch back to refocus.

I hope the information help and if you have any clues where to collect the log to further the investigation, please let me know :)

Update: I upgraded my Manjaro distro recently and the issue start to happen. After some package downgrading tests, I figured out xorg-server 1.20 is the culprit. Using older xorg-server works fine (1.19). Would be great if you can make autokey compatible with xorg-server 1.20. Otherwise I'm sticking with old xorg-server for now.

Thank you for digging and finding that

The same problem here with Kubuntu 18.10 and Plasma 5.14.4 (upgraded from 18.04) and for me this problem is not just about Qt apps but all apps lose focus when a script is triggered (for example mpv media player which is a pure cpp application).

I feel like it's a Plasma problem in general. As xdotool getwindowfocus tells me the focused window has not changed, but xdotool getactivewindow returns error after losing focus saying:

XGetWindowProperty[_NET_ACTIVE_WINDOW] failed (code=1)
xdo_get_active_window reported an error.

In addition, I also noticed that this only happens when I use modifiers (alt / ctrl) in send_keys.

Problem exists also in:

Operating System: Solus 4.1
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.13.2
Kernel Version: 5.5.4-148.current

Please use "xprop -root" to get the _NET_ACTIVE_WINDOW, it'll be more direct.

Reporting in, just noticed this too. Focus is lost but I can still type in the application.

OS: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-42-generic

I put those last two lines in interface.py around line 666 in the finish_send() function. It does work, but is not a great workaround as it makes the screen flash in an irritating way. Would be even more irritating if you were typing a series of expansions.

    def finish_send(self):
        self.__enqueue(self.__ungrabKeyboard)
        time.sleep(0.1)
        subprocess.call(["xdotool", "windowfocus", "'xdotool getwindowfocus'"])

Patch attached.

focus.patch.txt

I am not sure if this is the same issue, related or something completely different: when I use the qt-version (0.95.10) in Fedora 33 (32 was the same) and open the phrases menu, the menu has no focus and all subsequent key-strokes are getting somewhere else; I can't even close the menu with Esc. This isn't the case with gtk but for my purpose the gtk version is not option because (as far as I can see - I'm completely new to autokey) you cannot use letter shortcuts for the submenus in the gtk-version.

So unfortunately autokey is currently quite useless for me and I'd be seriously considering to use clcl in wine if it hadn't similar issues (actually more). I'm used to use hundreds of shell-code snippets in my current Windows-Supporter job (in submenus in up to 5 layers) and I'm now preparing for a Linux supporter job and it would be very sad if I wouldn't find something similar for Linux.

I consider this a serious bug. Does it fit to this issue or should open a new one?

Some data about my system:

System: Kernel: 5.8.15-301.fc33.x86_64 x86_64 bits: 64 compiler: gcc v: 2.35-10.fc33)
Desktop: Cinnamon 4.6.7 tk: GTK 3.24.23 wm: muffin dm: LightDM
Distro: Fedora release 33 (Thirty Three)
Machine: Type: Laptop System: TUXEDO product: N7x0WU v: N/A serial:
Chassis: No Enclosure type: 10 serial:
Mobo: TUXEDO model: N7x0WU serial: UEFI: American Megatrends v: 7.009
date: 05/14/2018
Battery: ID-1: BAT0 charge: 40.0 Wh condition: 40.0/43.8 Wh (91%) volts: 16.5/14.6
model: Notebook BAT serial: status: Full
CPU: Info: Quad Core model: Intel Core i7-8550U bits: 64 type: MT MCP arch: Kaby Lake rev: A
L2 cache: 8192 KiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31999
Speed: 800 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
5: 800 6: 801 7: 800 8: 800
Graphics: Device-1: Intel UHD Graphics 620 vendor: CLEVO/KAPOK driver: i915 v: kernel
bus ID: 00:02.0 chip ID: 8086:5917
Device-2: Chicony Chicony USB2.0 Camera type: USB driver: uvcvideo bus ID: 1-5:3
chip ID: 04f2:b59e
Display: x11 server: Fedora Project X.org 1.20.8 driver: modesetting
unloaded: fbdev,vesa resolution: 1: 1920x1080~60Hz 2: 2560x1440~60Hz s-dpi: 96
OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 20.2.0
direct render: Yes

@tnt Welcome to our project.
This appears to be a separate issue, so you can file it as one.

General comments:

This behavior is rather severe, so it is quite interesting that it has not been reported by anyone else. 0.95.10 has been out for quite awhile. And we do have at least a few other Fedora users.

You might want to create another "clean" user account on your system and try AutoKey there to see if it makes any difference. You could even do a local install of AutoKey to that user if you want to control for everything possible.

Or, you can clone this repository in the new account and try using the Zero Install method to test it.

The loss of letter shortcuts for menus when using the GTK front end does not seem like a deal breaker to me. Once everything is setup, the main menu isn't needed at all for normal use. I don't open mine for weeks at a time.

It is possible to build AutoKey scripts with GUI components such as menus which could be nested. This is a bit tricky to do and is probably best done by building the menus externally to AutoKey by directly calling a dialog manager such as yad or Zenity from something like a bash script.

Once the menus work, you could then call out to them from within AutoKey and have them return a unique descriptor or the actual content of what you want pasted and have AutoKey paste it for you.

If you are moderately proficient with bash, your favorite shell, or another programming language, there are ways to mass produce phrases outside of AutoKey.

If you are coming from AutoHotKey on Windows and have a lot of phrases to port over to AutoKey, I have written a very limited, proof of concept script which converts them to AutoKey phrases (available upon request.) It's only a starting point because it ignores most of AHK's options and won't handle multi-line phrases.

If these last few points interest you or you want to discuss anything else, come over to our support list or Gitter and we'll talk.