Disabling monitoring still swallows trigger hotkey

[Goli4thus]

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?

Xorg

Has this issue already been reported?

• I have searched through the existing issues.

Is this a question rather than an issue?

• This is not a question.

What type of issue is this?

Bug

Choose one or more terms that describe this issue:

• autokey triggers
• autokey-gtk
• autokey-qt
• beta
• bug
• critical
• development
• documentation
• enhancement
• installation/configuration
• phrase expansion
• scripting
• technical debt
• user interface

Other terms that describe this issue if not provided above:

No response

Which Linux distribution did you use?

manjaro

Which AutoKey GUI did you use?

Qt

Which AutoKey version did you use?

0.96.0

How did you install AutoKey?

AUR

Can you briefly describe the issue?

If a script is created, a window title is set and a single key (e.g. spacebar, a) is set as the hotkey, then even if monitoring is disabled (either via resp. global hotkey or via applet checkbox), the script's hotkey is still being swallowed by autokey-qt and the target application never gets the original key event.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

1. create a new script with something simple: `keyboard.send_keys("hoho")
2. set the script's window filter to the editor's window title (or use a regex; it makes no difference)
3. use a single key to trigger the script: e.g. spacebar or a
4. while monitoring is enabled, verify the script does what it's supposed to do
5. now disable monitoring (either via global hotkey or via applet checkbox)
6. type the script's trigger hotkey

What should have happened?

Once monitoring is disabled, the script's trigger hotkey should be passed to target application as if autokey-qt wouldn't be running in the first place. So it being completely transparent regarding key events.

What actually happened?

The target application doesn't receive the pressed hotkey, as if autokey-qt still captures it for some reason, but simply stopped triggering the resp. script.

Do you have screenshots?

I can provide some if really needed, but I think in this case the given explanation should be clear enough.

Can you provide the output of the AutoKey command?

#### monitoring enabled; script triggered via 'a' (result: works fine)
2023-07-04 22:12:27,002 DEBUG - autokey.service - Raw key: 'a', modifiers: [], Key: a
2023-07-04 22:12:27,002 DEBUG - autokey.service - Window visible title: 'Untitled 1 - Mousepad', Window class: 'mousepad.Mousepad'
2023-07-04 22:12:27,004 INFO - autokey.service - Matched Script "issue_re_disabled_monitoring" with hotkey and prompt=False
2023-07-04 22:12:27,005 DEBUG - autokey.service - Script runner executing: Script('issue_re_disabled_monitoring')
2023-07-04 22:12:27,007 DEBUG - autokey.iomediator.iomediator - Send via event interface
2023-07-04 22:12:27,011 DEBUG - autokey.service - Input queue at end of handle_keypress: deque(['a'], maxlen=150)
2023-07-04 22:12:27,011 DEBUG - autokey.interface - Sending string: 'hoho'

#### disable monitoring via global hotkey `shift + meta + k` (result: seemingly works fine)
2023-07-04 22:12:32,922 DEBUG - autokey.iomediator.iomediator - Key.SHIFT pressed
2023-07-04 22:12:32,930 DEBUG - autokey.iomediator.iomediator - Key.SUPER pressed
2023-07-04 22:12:33,828 DEBUG - autokey.service - Raw key: 'k', modifiers: [<Key.SHIFT: '<shift>'>, <Key.SUPER: '<super>'>], Key: K
2023-07-04 22:12:33,828 DEBUG - autokey.service - Window visible title: '*Untitled 1 - Mousepad', Window class: 'mousepad.Mousepad'
2023-07-04 22:12:33,829 DEBUG - autokey.configmanager.configmanager - Triggered global hotkey using modifiers: [<Key.SHIFT: '<shift>'>, <Key.SUPER: '<super>'>] key: 'k'
2023-07-04 22:12:33,832 INFO - autokey.service - Pausing - service now marked as stopped
2023-07-04 22:12:34,258 DEBUG - autokey.iomediator.iomediator - Key.SUPER released
2023-07-04 22:12:34,274 DEBUG - autokey.iomediator.iomediator - Key.SHIFT released

#### press the same hotkey `a` again (result: letter "a" is never reaching text editor)
2023-07-04 22:12:36,923 DEBUG - autokey.service - Raw key: 'a', modifiers: [], Key: a
2023-07-04 22:12:36,924 DEBUG - autokey.service - Window visible title: '*Untitled 1 - Mousepad', Window class: 'mousepad.Mousepad'

Anything else?

No response

[josephj11]

We're missing something here. If this was a "global" problem, we would probably have had many reports.

Can you reproduce this problem in other applications such as your terminal or kate?

Although it's legal, it's not a good idea to use unmodified normal characters as triggers because the normal key becomes unavailable for other uses. This can be limited by using a window filter as you appear to have done.

Your trace doesn't show AutoKey doing anything special with the key when monitioring is disabled.

[Goli4thus]

Trying further applications

Can you reproduce this problem in other applications such as your terminal or kate?

I've just tried it with the following applications (using a as the hotkey):

• xfce4-terminal
• gnome-terminal
• urxvt
• mousepad
• kate
• firefox

For each of those:

• monitoring enabled: works
• monitoring disabled: hotkey not reaching target window

I've also tried the same minimal test using ctrl + a as the hotkey.

• xfce4-terminal
• gnome-terminal
• urxvt
• mousepad
• kate
• firefox

For each of those (again):

• monitoring enabled: works
• monitoring disabled: hotkey not reaching target window

Shouldn't there be more issue reports?

We're missing something here. If this was a "global" problem, we would probably have had many reports.

I'm using Xfce if that matters.
I agree, if this is affecting that many applications, then it's bit strange why I couldn't find any bug reports.
Then again, v0.96.0 is the latest version released one month ago. I don't how many users already use that version.
Additionally, I don't know how many of those use disable monitoring feature. For any potential issue, there gotta that one first issue report. So maybe that's what this is.

Trying older versions of autokey

I got curious if older versions have the same behavior.
I've followed this "zero instlalation method": https://github.com/autokey/autokey/wiki/Installing#zero-installation-method

I've focused on git tags and just used mousepad as the target application.

• v0.95.0; same behavior
• v0.94.0; same behavior
• ak-0.93.0; same behavior
• ak-0.92.0; same behavior
• ak-0.91.0; same behavior
• ak-0.90.4; same behavior

Well, doesn't seem like a regression then.

About using single keys as hotkeys

Although it's legal, it's not a good idea to use unmodified normal characters as triggers because the normal key becomes unavailable for other uses. This can be limited by using a window filter as you appear to have done.

Yes, I'm aware of the implication of using a single key like spacebar or a letter as a hotkey.
As you've noted, this only really makes sense with a rather restrictive window filter.
The minimal example I've described here is just for reproducing this issue.

My actual usecase makes use of regex based window filter and uses spacebar as the trigger. It's about Reaper and plugin windows. spacebar isn't always about text input. In apps like e.g. DAWs, video editors, etc. it often is associated with
play/stop.

About the trace output

Your trace doesn't show AutoKey doing anything special with the key when monitioring is disabled.

Yes, nothing stuck out to me either. Except that it still registers the hotkey being pressed despite monitoring being
disabled. I don't know what the architecture of autokey is like and how disabled monitoring is supposed to work; e.g.:
a) "play dead and and let hotkeys pass by unaffected" or
b) "capture hotkeys, but deliberately forward them to make it look like autokey is changing nothing"

Anyone else?

At this point I'm not sure if:
a) there's a systematic problem on two machines of mine (both using manjaro with Xfce) or
b) this "issue" is the intended behavior so far

Can anyone else reproduce this on their end?

Is the expected behavior of disable monitoring really that the resp. hotkeys are not being passed along to the target application? If so, shouldn't there be some way to temporarily disable autokey to make hotkeys register in target application "as is" without closing autokey first?

[Elliria]

Interesting. This is naughty behavior. AutoKey is hanging on for dear life.

I can replicate this issue in AutoKey 0.95.10 under Kubuntu 22.04 LTS using Xorg. I didn't even need to use the window filter. My test:

1. Create a script that contains this code: dialog.info_dialog(message="FOO")
2. Give it this abbreviation: triggerthisscript
3. Make sure that Remove typed abbreviation is enabled.
4. Click the OK button to save the abbreviation.
5. Click Save in the menu to save the script.
6. Open a text editor.
7. Type the abbreviation.
8. Success: Note that the dialog opened and the abbreviation is not in the text editor.
9. Click the AutoKey icon in the tray.
10. Click to remove the check-mark from the "Enable Expansions" option in the context menu.
11. Open the text editor.
12. Type the abbreviation.
13. Failure: Note that the dialog opened, the abbreviation is not in the text editor, and the "Enable Expansions" option in the AutoKey icon's context menu has a check-mark in it again.

[Elliria]

I never noticed it before because when I don't want AutoKey to intervene, I shut it down.

[josephj11]

Thanks to both of you for the extensive testing. Looks like the code will have to be examined in detail.

I don't think many people do disable AutoKey expansions while AutoKey is running which may explain why it wasn't reported before.

Having expansions disabled is "logically" the same as a window filter that doesn't match. Both should pass whatever is typed without any interaction.

The only other thing to test might be whether autokey-gtk has the same issue. I suspect it does because this sounds like something in the code common to both versions.

@Goli4thus Do you see the expansions being reenabled like @Elliria does? That's also pretty weird and a bug.

@Elliria Does this seem like something you can investigate or is this too deep into the code? I can add a help wanted tag if that's the case.

[Goli4thus]

autokey-gtk

I tried the mentioned tests with mousepad using both triggers. Result is the same. So very likely something about autokey-common.

testcase by Elliria

I used autokey-gtk again.
I could reproduce everything except that last part regarding this:

"Enable Expansions" option in the AutoKey icon's context menu has a check-mark in it again.

In my case the checkmark was off, but the behavior was as described.
BTW: That checkbox at times being properly disabled and at times seemingly being stuck on enabled might be another issue.

[Elliria]

I 'm unlikely to figure it out on my own, but I can help.

First, I just did the test in AutoKey Qt and that works perfectly for me. I'm able to enable and disable monitoring at will using the AutoKey panel icon's context menu check-box and it works every time and never misbehaves.

This is a GTK issue. The moment I do the test in AutoKey GTK, it falls over. What I failed to note earlier (and should have, because I realize it did happen during my first tests), was that the very first time I disabled monitoring in the AutoKey panel icon's context menu, I got a system notification about AutoKey crashing. Here's a screenshot of the notification and the little sad-face icon next to the AutoKey panel icon that opens the crash report:

I clicked the sad-face icon and decided not to file the report, but I let it gather the information and then looked that over. This is what it says went wrong:

autokey-gtk crashed with AttributeError in on_enable_toggled(): "CheckMenuItem' object has no attribute 'active'

I did a grep for CheckMenuItem in the AutoKey 0.96.0 code and this was the result:

$ grep -r "CheckMenuItem" *
grep: lib/autokey/gtkui/__pycache__/notifier.cpython-310.pyc: binary file matches
lib/autokey/gtkui/notifier.py:        enableMenuItem = Gtk.CheckMenuItem(_("Enable Expansions"))

If you do a search for CheckMenuItem and actiive in the lib/autokey/gtkui/notifier.py file, there are several results. I'm not seeing what's wrong, but maybe one of you will.

[Elliria]

I thought I'd add these searches on GitHub instead of on my machine:

• Search lib/autokey/gtkui/notifier.py for CheckMenuItem.
• Search lib/autokey/gtkui/notifier.py for active.

[josephj11]

Good catch!

This might be an updated library module. It depends on how far back the problem goes. I don't expect anyone to resurrect a lot of older versions though. That would be hard to do because it would require old depenencies too.

[Elliria]

Even if we found a version that didn't do it, there would be a whole lot of commits to look through to see what changed where to figure out what went wrong. Hopefully someone will be able to look at the error message and the links above and see what needs to be adjusted. Obviously the CheckMenuItem needs an active attribute, but where and how is the question.

[ineuw]

These changes have nothing to do with Autokey. Similar problems occur with other apps as well. Most were in upgrade during the past 3-4 years, and they are just being implemented. I am spending hours on every issue, looking for solutions for the changes. Also, there just isn't enough volunteers globally. Perhaps we can get AI to search and correct the code?

[josephj11]

@ineuw Maybe Chat GPT 5.

Linux already has lint for C-like languages. IDK if there's anything similar for Python. Something like that with AI added would be quite interesting, but: it would still require a skilled coder to review the changes. It will be a lot longer before I trust AI. And, something AI based would probably replace all of AutoKey.

I have some stupid simple actions I do multiple times a day that would take me forever to code in AutoKey, but if an AI could just watch me do them a few times and learn them, it would probably be easy for it to do them for me.

Coding is much more primitive than watch and learn would be.

[Elliria]

Our current linting is rather gentle and is done using the flake8 command. If you'd like to do some hard-core linting of the code, clone AutoKey and make these changes to it:

1. Comment out this section of the code at the bottom of the setup.cfg file:

   # [testenv:lint]
   # deps = coverage
   #     {[testenv]deps}
   #     flake8
   # commands = flake8 --count --select=E9,F63,F7,F82 --show-source --statistics --builtins=_ --max-complexity=10 --max-line-length=127 lib/autokey
   # passenv = {[testenv]passenv}
   

2. Add this section to the bottom of the setup.cfg file:

   [testenv:lint]
   skip_install = True
   deps =
   	flake8
   	flake8-bugbear
   ### The following line detects and stops the build if there are Python syntax errors or undefined names. It also gives this output: lint: commands succeeded
   commands = flake8 --count --select=E9,F63,F7,F82 --show-source --statistics --builtins=_ --max-complexity=10 --max-line-length=127 lib/autokey
   ### The following line gives this output: InvocationError and lint: commands failed and lots of errors that need to be fixed listed
   # commands = flake8 --count --show-source --statistics --builtins=_ --max-complexity=10 --max-line-length=127 lib/autokey
   ### The following line gives this output: InvocationError and lint: commands failed and lots of errors that need to be fixed listed (different from those in the previous command)
   # commands = flake8
   passenv = {[testenv]passenv}
   

3. Run tox -e lint inside the cloned repository's folder on your local machine to see all the lint errors in your code.

Notes:

• The flake8 package must be installed on your system for this type of linting to be used (it's in the Ubuntu repositories).
• If you enable either of the two bottom flake8 commands instead of the top one, you'll get an InvocationError message that seems to be a known bug, but you'll also see the actual errors in the AutoKey code.
• More information on flake8: https://flake8.pycqa.org/en/latest/
• You can use flake8 on the command-line by invoking it against any directory or Python module:
  • For example:
    • Lint a file: flake8 /path/to/file.py
    • Lint a directory recursively: flake8 /path/to/directory
    • Lint the current directory recursively: flake8
    • Lint the Python files in the current directory non-recursively: flake8 *.py
    • You can also use any of the command-line options on the command-line, like those in the script above, for example.

[ineuw]

Thanks, I downloaded the source already and will let you know what happened.

[josephj11]

@Elliria That sounds like a great utility for developers (not me!). I've got way too many hours devoted to this project already and don't need to expand my roles.

Is there any way this would be relevant for checking user scripts? If so, it would be a great option to add a button for next to editing panel.

Your notes would be great in the wiki somewhere under developers.
I had trouble understanding where the comments stopped and the commands started. Some formatting should fix that.

[Elliria]

I forgot to mention that the tox package also needs to be installed if you want to run the AutoKey tests, @ineuw. If you just want to run flake8 on any of the AutoKey files or directories (or your own files or directories), then all you need to install is the **flake8) package. I've updated the message above.

[Elliria]

It is a great tool for developers, @josephj11. In fact, ever since I discovered it, I've been trying to make it a habit to test any and all of my own personal (non-AutoKey) code with it.

It might or might not be useful for checking users' scripts. There would be two challenges: First, someone who knows how to incorporate a new option into the editor would be needed to make it available. Second, we would either have to make a decision on which options the linter should test for or a menu of options would need to be made available to the user.

I adjusted the comments and commands in the code snippet above. Are those better? Note that the tests that AutoKey already runs with tox and flake8 are doing their job and don't need to be changed. Those optional lines of code above are just something I do for the heck of it for brutal linting and wouldn't be a permanent change we would want to make to AutoKey. When cloning AutoKey and making the changes, it's expected that you'd be using the above snippet for informational purposes and would trash the clone afterwards.

The flake8 command, however, can stay as a permanent and useful tool for your Python arsenal, though.

[ineuw]

Much thanks for the instructions. Installed tox and flake8 and will post back soon.

[ineuw]

Would this be of any help? AyatanaAppindicators3? I am just fishing.

[josephj11]

IDK. I have seen that referenced in our dependencies before and vaguely recall an issue with it not being available. See #816.

[ineuw]

This issue is also related to the post with GTK-4 and Ayatana... and the whole GTK menu.

[Elliria]

Much thanks for the instructions. Installed tox and flake8 and will post back soon.

Cool. I hope you enjoy them both. I whiled away a few hours messing around with each of them

[ineuw]

I suspected previously, that our copies are not the same. The deb file, the pip3 installation files are not compiled from the same master. The snippet to be replaced was not in the master.
My installed copy is by the deb files downloaded from Github.

[testenv:lint]
deps = coverage
    {[testenv]deps}
    flake8
commands = flake8 --count --select=E9,F63,F7,F82 --show-source --statistics --builtins=_ --max-complexity=10 --max-line-length=127 lib/autokey
passenv = {[testenv]passenv}

Before. I was using this, but is no longer valid according @josephj11. Why can't everything be the same?

Here are the tox -e lint results. Do you see anything wrong?
tox-e_lint.txt

[josephj11]

@ineuw I don't remember what I said about that zip file. Can you point me to my comment(s) so I can review them?

Theoretically, that should be the version of 0.96.0 that we created and released at the same time as the corresponding debs were created. So they should be the same, but behind anything that's been done in master and develop since then.

[ineuw]

The 0.96.0.zip version needed an additional library file to eliminate unwanted error messages during debugging. The python libraries were updated since that time, and the messages disappeared when installing from the .deb files.

I switched to the 0.96.0.deb packages which are better for me, because I only install GTK in Linux Mint, and only Qt in Kubuntu 22.04 to follow user issues.

However, two days ago, I noticed that the v0.96.0 .deb, .zip, and the downloaded source package are not exactly the same. It seems that additions to the main branch were not repackaged and placed in the downloads. Of course, this would require a revision number and documentation.

[josephj11]

@ineuw Good catch!

@ineuw and @Elliria These discrepancies probably shouldn't exist so they need to be detailed so we can figure out why each one occurred and what, if anything, we need to do to eliminate them now and prevent them (or similar ones) from recurring.

[Elliria]

I'm always working with the develop branch when I try these things out and make changes. Very rarely do I do anything with the master branch, and that's only if there's no choice.

To get a copy of the develop branch to mess around with, you can clone it. There are instructions for trying out a clone of AutoKey in the wiki. For step 2, you'd want to follow the Clone a repository branch instructions to get the develop branch.

Please don't do these experiments on your installed copy of AutoKey. I realize that if you comment something out and replace it with something else, you'll know what you did and can undo it, but you never know what might go wrong. The above steps were just something I did to get a good look at what's not up to snuff in our code and is not something we would normally use.

I think the reason why the files are different is that they were created at different times and possibly by different people.

It looks like tox is missing some stuff that it needs. If you follow all of the steps in the link above, it should have them.

You might want to try flake8 instead of tox, @ineuw. That one is a quick installation from the Ubuntu repositories and can then be run on any Python file or directory of Python files on your computer to generate a similar list. There's no need to edit any of the AutoKey files before running it, so it can be used on your installed AutoKey or a downloaded or cloned one. It also offers many options you can use to insist on certain types of results. Last, but not least, it doesn't need a special environment in which to be run. I like flake8 so much that I've now incorporated it into Geany so that it's a button-click away any time I've got a Python file open.

[Elliria]

@ineuw Good catch!

@ineuw and @Elliria These discrepancies probably shouldn't exist so they need to be detailed so we can figure out why each one occurred and what, if anything, we need to do to eliminate them now and prevent them (or similar ones) from recurring.

This should go into its own issue report.