autokey

autokey copied to clipboard

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?

• [X] I have searched through the existing issues.

Is this a question rather than an issue?

• [X] This is not a question.

What type of issue is this?

Bug

Choose one or more terms that describe this issue:

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

Other terms that describe this issue if not provided above:

GTK4, LibAdwaita

Which Linux distribution did you use?

Pop!_OS 22.04 (Ubuntu-based)

Which AutoKey GUI did you use?

GTK

Which AutoKey version did you use?

0.95.10-2

How did you install AutoKey?

Distribution's repository

Can you briefly describe the issue?

Shortcuts are not working inside GTK4 + LibAdwaita apps. I noticed that the text cursor blinks if I press the shortcuts, but nothing else seems to happen.

No messages appeared in the terminal when running one of the apps I tested through it.

Not sure if it's an AutoKey's need to support GTK4, or if it's a GTK4 issue, so reporting it here first.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

(assuming you already have AutoKey installed and configured with shortcuts)

1. Open a GTK4 + LibAdwaita app (such as Gnome Text Editor, Flatseal v2.0 etc.)
2. Press a shortcut you have configured in AutoKey
3. See how it doesn't work

What should have happened?

The shortcut should have worked.

What actually happened?

Nothing happened, except that pressing the shortcut multiple times caused the text cursor in text fields to blink.

Do you have screenshots?

No response

Can you provide the output of the AutoKey command?

The only apparently unusual message I saw was the following, but it happened when focused on other apps as well, not only the ones where the issue being reported here happened.

2023-05-02 15:31:46,648 ERROR - service - Ignored locking error in handle_keypress
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/autokey/service.py", line 207, in __tryReleaseLock
    self.configManager.lock.release()

Anything else?

Tested with both Flatpaks and native packages (.deb).

Welcome to the AutoKey community @hyuri !

This is odd. Several things to consider.

First, test without flatpaks. We need to establish base functionality first.

Pop OS appears to be based on Ubuntu, so our packages should be compatible with it with no issue.

You can also get our latest version, 0.96.0, here and install it using these instructions. This probably won't affect this particular issue, but you will get a lot of bug fixes and a few new features. It should get rid of that exception you are seeing.

The first thing we need to verify is that you are using xorg/X11 because, starting with Ubuntu 22.04, the default window manager is Wayland and AutoKey is not compatible with Wayland (yet - we're working on it).

I wrote a bash script for this. Save it as a file and make it executable then run it. If you save it in $HOME/bin, your command line shell should be able to find it without specifying its full path.

#!/bin/bash
## window_manager
session=$(loginctl | awk '
NR != 2 {next}
{print $1}')
wm="$(loginctl --no-pager show-session $session -p Type)"
echo -n "Your window manager is "
cut -c 6- <<<"$wm"

On my system, the result is:

$ window_manager
Your window manager is x11

If it says Wayland, then you have to log out and log back in selecting Xorg on the login page.

If it does say x11 or you do the above and it still doesn't work, then you need to run a trace so we can figure out what's going on.

Once it works on native applications, we can see about flatpak applications.

This page in the Ubuntu Forums may be of some help when trying to use AutoKey with flatpaks.

That pretty much says "don't use flatpak application windows as targets of AutoKey actions."

That being said, I routinely use AutoKey with a version of kcalc that is installed as a flatpak on my system and it works fine. I do really simple things like copy/pasting to and from the clipboard, not anything fancy, though.

Yep, it works fine with non-GTK4 + LibAdwaita flatpaks.

Welcome to the AutoKey community @hyuri !

Thank you!

First, test without flatpaks. We need to establish base functionality first.

Same happening with Gnome Text Editor v42 (GTK4 + LibAdwaita) repository/deb version.

Could it be a problem with GTK4 and/or LibAdwaita? I couldn't easily find non-GTK4 LibAdwaita or non-LibAdwaita GTK4 apps available as both Flatpak and Deb to test, so it's hard for me to know which one is the offender.

The first thing we need to verify is that you are using xorg/X11 because, starting with Ubuntu 22.04, the default window manager is Wayland and AutoKey is not compatible with Wayland (yet - we're working on it).

By the way, I'm very excited for the Wayland version! AutoKey is the last thing missing for me to move to Wayland. Thank you for working on it!

But yes, I got: Your window manager is x11

Until someone who knows a lot more than I do looks at this, then the only things I can think of are to spin up a VM with an environment that does work or avoid the things that don't work in your current environment. We also need any information necessary to recreate the problem like the particular flatpaks that don't work.

You might also see if you can get any traction here or on their listserv.

If you can interest any devs on their end, we'll do our best to cooperate with their efforts. If they really believe that flatpaks are the future, they should be willing to help get them to work with tools like AutoKey that make everything easier and faster.

There seems to be a general trend of people doing things new ways that just aren't compatible with existing software requirements. Wayland is a bit like that as well.

Flatpaks have been ruled out by experiencing the same issue with the repository version of Gnome Text Editor.

The issue is only happening with GTK4 + LibAdwaita apps, all of them, both flatpak and debian package/repository.

Gnome Text Editor is an example, if anyone wants to test.

That's what we needed to know.

While you're waiting - which could be quite a while because we currenitly have only two devs, one who is working on Wayland and some refactoring and the other who is a very enthusiastic beginner with Python and AutoKey source - you should probably upgrade to 0.96.0. That's what any fixes will be based on. That should eliminate the execption you are seeing. Once you do that, then run a trace of one action that doesn't work and let us see it. There might be some clues in it to help solve this.

Also, if you haven't been there yet, take a look at our wiki There are a number of helpful articles there and lots of example scripts.

If and when we do get a fix for this, it will initially be in a branch on GitHub that you will probably want to clone and test on your system. We'll tell you which branch to clone using git. Then you can test it following these instructions.

We are currently updating a lot of our documentation, so check with us when you're ready in case the latest documentation you need is temporarily somewhere else.

That pretty much says "don't use flatpak application windows as targets of AutoKey actions."

It mentioned "flatpak config setting on a per-program realm that will let you allow other programs access" as a possible way to get around the issue. I poked around a bit and found the https://docs.flatpak.org/en/latest/flatpak-command-reference.html page. If you search that page for access, you'll find several ways that access to flatpaks can be configured. Maybe one of them will be the magic incantation that opens the gates for AutoKey.

Maybe one of them will be the magic incantation that opens the gates for AutoKey.

Are you talking about packaging and distributing AutoKey as a Flatpak? AutoKey has no issues working with flatpak apps. The issue reported here is related to GTK4 and/or LibAdwaita, not flatpaks.

It was about AutoKey interacting with flatpaks. If it's about GTK4 and LibAdwaita, I've got no idea. I did some quick Googling and it seems that LibAdwaita is just a way to separate theming from GTK, so I can't imagine how that could interfere with AutoKey. So far, I haven't come up with any good Google searches that would turn up something similar, but I'll keep looking.

. I poked around a bit and found the https://docs.flatpak.org/en/latest/flatpak-command-reference.html page. If you search that page for access, you'll find several ways that access to flatpaks can be configured. Maybe one of them will be the magic incantation that opens the gates for AutoKey.

Good clarification.

Nothing happened, except that pressing the shortcut multiple times caused the text cursor in text fields to blink.

If this is not too stale, . . . .

What shortcut? What is a shortcut by your definition? I also have problems with controls involving GTK etc., and that is why more detail is important because our info will bring us closer to a solution.

I used flatpak and Autokey was never affected. Autokey-gtk and Python are not the cause of the problem. But, bugs in GTK, LibAdwaita, may affect it's activation. Then, by mentioning GTK4 and LibAdwaita in conjunction with Autokey 95.10, - perhaps installing 96.0 would be a first step to finding the problem.

@ineuw Installing 0.96.0 is always a good idea, especialliy as that's the version any fixes would be applied to, but I'm not sure it would impact this issue.

@hyuri We are still waiting to see an AutoKey trace.

Just tested the GTK4/LibAdwaita issue on Debian 12 (X.Org) with Autokey v0.96.0. Test scenario is following: press <ctrl>+<right> paste <end> using Keyboard. Test performed with gedit v44.2 (GTK3) vs Text Editor v43.2 (GTK4/LibAdwaita). Both programs installed from the Debian repository (no Flatpak or Snap).

Autokey does not work as expected in Text Editor. Expected behavior: cursor is moved to the end of line. Actual behavior: cursor stops blinking and disappears. The autokey -l does not output any error or stack trace:

For gedit:

2023-06-27 14:03:27,180 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2023-06-27 14:03:27,254 DEBUG - autokey.service - Raw key: <Key.RIGHT: '<right>'>, modifiers: [<Key.CONTROL: '<ctrl>'>], Key: Key.RIGHT
2023-06-27 14:03:27,255 DEBUG - autokey.service - Window visible title: '*Untitled Document 1 - gedit', Window class: 'gedit.Gedit'
2023-06-27 14:03:27,255 INFO - autokey.service - Matched Phrase "end" with hotkey and prompt=False
2023-06-27 14:03:27,256 DEBUG - autokey.iomediator.iomediator - Send via event interface
2023-06-27 14:03:27,259 DEBUG - autokey.interface - Send special key: ['<end>']
2023-06-27 14:03:27,410 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released

For Text Editor:

2023-06-27 14:05:37,296 DEBUG - autokey.iomediator.iomediator - Key.CONTROL pressed
2023-06-27 14:05:37,364 DEBUG - autokey.service - Raw key: <Key.RIGHT: '<right>'>, modifiers: [<Key.CONTROL: '<ctrl>'>], Key: Key.RIGHT
2023-06-27 14:05:37,364 DEBUG - autokey.service - Window visible title: 'Lorem asdfasfd ipsumasdf (Draft) - Text Editor', Window class: 'gnome-text-editor.gnome-text-editor'
2023-06-27 14:05:37,364 INFO - autokey.service - Matched Phrase "end" with hotkey and prompt=False
2023-06-27 14:05:37,366 DEBUG - autokey.iomediator.iomediator - Send via event interface
2023-06-27 14:05:37,367 DEBUG - autokey.interface - Send special key: ['<end>']
2023-06-27 14:05:37,551 DEBUG - autokey.iomediator.iomediator - Key.CONTROL released

Shortcuts are not working in other GTK4/LibAdwaita apps like Files v43.2, Software v43.4 etc...

Can you post the script please?

On my system (Kubuntu 22.04 LTS):

• End does nothing if pressed by itself.
• Ctrl+End takes me to the end of the current line.
• Ctrl+right arrow moves the cursor to the right of the current word. Repeated presses of that key-combination will continue to do that all the way to the end of the document (not just to the end of the current line of text).

@ineuw here. Let me know if that helps! end.zip

@ineuw I downloaded the zip file and it appears to be safe to open.

@petrstepanov, Your premises are wrong.

1. You can't use a phrase for copy and paste.
2. You need a script which uses the Python programming language to generate keyboard commands.
3. Please stay away from using "ctrl", in any combination as a hotkey. The ctrl+end is a "system" key, as many are. "ctrl" is the most used modifier in hotkeys in all applications. Instead, combine the hotkeys with "super" aka "the windows key", "alt" or "shift" modifiers, like "super+end", etc.
4. Finally, the word <end> is enclosed by <> which requires special treatment. this is my post of yesterday, about using html type codes) It's near the end of the post.
5. If you want only the word pasted, use keyboard.send_keys('<end>') in a script.
6. I you give me more information, I will gladly guide you.

We don't need content, we need the steps you take to achieve it. Is the source a browser? Is the destination is a browser? Which browser? I ask because some browser behavior applies to all browsers, and some not. Firefox is aware of clipboard activity during copy and paste, and I must assume Chrome as well.

Please contribute only plain text when helping others with issues, @petrstepanov. I, for one, wouldn't open that zip file.

@Elliria I agree that compressed/archived files are not a good idea. However, if you use ark to open them, you can see what's in them and control where they can be expanded to without exposing yourself to much (none that I know of) danger.

@petrstepanov GitHub supports markdown. If you insert structured text in a post use a prefix of a blank line followed by a line with only three backticks on it and a suffix of a line with only three backticks on it followed by a blank line, your text will be preserved and may even have syntax highlighting. Alternatively, you can always save your text on the cloud somewhere and provide a link to it in your post. I recently posted an AutoKey script on Gitter which creates a markdown link from a URL in the clipboard and a label in the PRIMARY selection.

Here is a very simple script which has the same issue with Gtk4 apps like Nautilus and Gnome Text Editor (works fine everywhere else, also in the Slack flatpak for example):

output = system.exec_command("date --rfc-3339=date")
keyboard.send_keys(output)

I attached it to <super>+i with the gui. Fedora 37, X11, Auokey 0.95.10.

I've tried quite some solutions for this seemingly simple task (all based on Gnome shortcuts and some tool to type text), but AutoKey is the first that works reliably and enters text quite fast. Would be a shame if Gtk4 support would break that streak of success. Let me know if/how I can help fix this.

@dreua Thanks for the offer! Don't currently know of any way to "fix" it as it appears to occur in the interface libraries we use or in the receiving applications.

But, that's not the way you should do it.

Try this:

output = system.exec_command("date --rfc-3339=date")
clipboard.fill_clipboard(output)
time.sleep(0.1)
keyboard.send_keys("<ctrl>+v")

That should work almost everywhere.

Once it works, you can optionally improve it by doing things like saving the current clipboard contents first and then restoring them at the end.

This approach should always be your first option. In addition to avoiding a lot of timing issues wth slow applicatons, it also suppports "output" that contains multibyte characters (UTF-8...). The keyboard API calls do not support these.

You should only use the keyboard API calls when your output contains active keys (that move the cursor or otherwise take effect as soon as they are pressed) or if you use any AutoKey macros like cursor, code, or script.

See this and the linked articles for more info.

Some other way you might be able to help with this:

If you have some Python coding skills you could get this to work. I believe @sebastiansam55 has already done some work on this, but I don't see it referenced in the issue.

You could also look into testing/working on our new Wayland interface (which will probably have its own set of issues). The issue is here, but the code is here. I'm sure Sam will provide any details you need for getting started with it. I think it's ready for alpha testing and you don't need to be a coder to help with testing.

I tried your script as is, and it returns the date string as 2023-07-13. Use the following in a terminal dpkg -l "*gtk*" | grep ii>gtk.txt to see which version of GTK is installed. And, you can also install gtk3.

I am using Linux Mint Cinnamon 21.1 with Autokey-gtk 0.96 and GTK3. Although there are a number of GTK4 files placed in the system, I can't tell if they are installed.

I also suggest two changes, even though your script works as is. Use single quote instead of double. This passes on the exact value!

Also, try keyboard.send_keys('<shift>+<insert>') to paste, instead of '<ctrl>+v', and use '<ctrl>+<insert>' instead of '<ctrl>+c'. This circumvents mouse copy and paste activity.

Additional info for browsers, especially Firefox, because of windows within windows, you should set focus in the code, twice in case of using gMail, which is an additional Window.

Use single quote instead of double. This passes on the exact value!

@ineuw Can you point me to something that explains the difference between the two forms of quoting? I thought I saw somewhere that they were identical.

Also, try keyboard.send_keys('+') to paste, instead of '+v', and use '+' instead of '+c'. This circumvents mouse copy and paste activity.

Markdown ate your syntax. I fixed it in your post by adding backtiicks.

Additional info for browsers, especially Firefox, because of windows within windows, you should set focus in the code, twice in case of using gMail, which is an additional Window.

I don't understand this. Can you say it another way, etc.?

Info on quoting:

• Stack Overflow: https://stackoverflow.com/questions/6697753/difference-between-single-and-double-quotes-in-bash
• TLDP: https://tldp.org/LDP/abs/html/quotingvar.html

I'm pretty sure this is Python code and in Python single and double quotes don't make a difference with the nitpicker's exception that you don't need to escape single quotes in a double quoted string and vice versa. There are conventions but we are already too far off topic to discuss them here imo.

@Elliria Both your links are on quotes in Bash, may I suggest that you replace it with a link to coding style - Single quotes vs. double quotes in Python - Stack Overflow.

The part of the code that @ineuw is referring to is the double-quoted Bash command:

output = system.exec_command("date --rfc-3339=date")

Those double quotes should be replaced with single quotes for the reasons in those links above.

As to Python quotes, they're much simpler. PEP 8 says that both single quotes and double quotes work equally well for strings, although if your string contains one, then you'll want to use the other to quote the string. Triple double-quotes """ are used to create docstrings or text blocks. Interestingly, although no mention is made of triple single-quotes ''', PEP 8 specifically says you should always use triple double-quotes """. If you follow the link in it, it explains that this is in case you use any backslashes in your docstrings.

As a naughty girl, I've always used """ and ''' interchangeably for docstrings and text blocks, just because I could, but I suppose it's good to know what the conventions say you should use.

This is a Python string containing a bash command. The quotes are Python and the bash inside contains no quotes. I see now why you thought of bash but trust me when I say these Python quotes are not the issue here.