Package Details: autokey-qt 0.96.0-2

Git Clone URL: https://aur.archlinux.org/autokey.git (read-only, click to copy)
Package Base: autokey
Description: A desktop automation utility for Linux and X11 - common data
Upstream URL: https://github.com/autokey/autokey
Licenses: GPL3
Submitter: dark-saber
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 66
Popularity: 0.178735
First Submitted: 2019-02-12 12:21 (UTC)
Last Updated: 2022-06-06 18:23 (UTC)

Latest Comments

AvidSeeker commented on 2022-06-30 12:29 (UTC)

autokey-common could not find packages Tried installing autokey from AUR.

yay -S autokey-common

gives the error:

 -> Could not find all required packages:
        wmctrl (Wanted by: autokey-common)
        xautomation (Wanted by: autokey-common)
        xorg-xwd (Wanted by: autokey-common)

am I missing some repos in my mirror list? I tried manually installing these packages (with adding them to PATH), still not solved.

BlueDrink9 commented on 2022-06-06 00:02 (UTC)

New release! https://github.com/autokey/autokey/releases/tag/v0.96.0

ronjouch commented on 2022-04-15 16:22 (UTC)

@yochananmarqos confirmed! Thanks for the quick fix, and thanks for the package maintenance.

yochananmarqos commented on 2022-04-15 16:02 (UTC)

@ronjouch: Oops. It's fixed now.

ronjouch commented on 2022-04-15 15:23 (UTC)

Even after removing autokey-gtk autokey-common , installing -5 is impossible because of conflicts:

error: failed to commit transaction (conflicting files)
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/LICENSE exists in both 'autokey-common' and 'autokey-gtk'
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/METADATA exists in both 'autokey-common' and 'autokey-gtk'
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/RECORD exists in both 'autokey-common' and 'autokey-gtk'
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/WHEEL exists in both 'autokey-common' and 'autokey-gtk'
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/entry_points.txt exists in both 'autokey-common' and 'autokey-gtk'
/usr/lib/python3.10/site-packages/autokey-0.95.10.dist-info/top_level.txt exists in both 'autokey-common' and 'autokey-gtk'
Errors occurred, no packages were upgraded.

mpj4 commented on 2022-02-02 07:50 (UTC)

Can't connect to display ":0.0": b'Invalid MIT-MAGIC-COOKIE-1 key'

fixed it by deleting $HOME/.Xauthority and rebooting

hicklemon commented on 2021-12-14 17:44 (UTC)

I'm on python 3.10.1 and I got it working again. I had to manually reinstall autokey-common && autokey-gtk

Archanfel80HUN commented on 2021-12-14 17:16 (UTC) (edited on 2021-12-14 17:20 (UTC) by Archanfel80HUN)

Broken with python 3.10.x (works with 3.9.x):

Traceback (most recent call last): File "/usr/bin/autokey-gtk", line 33, in <module> sys.exit(load_entry_point('autokey==0.95.10', 'console_scripts', 'autokey-gtk')()) File "/usr/bin/autokey-gtk", line 22, in importlib_load_entry_point for entry_point in distribution(dist_name).entry_points File "/usr/lib/python3.10/importlib/metadata/init.py", line 919, in distribution return Distribution.from_name(distribution_name) File "/usr/lib/python3.10/importlib/metadata/init.py", line 518, in from_name raise PackageNotFoundError(name) importlib.metadata.PackageNotFoundError: No package metadata was found for autokey

hicklemon commented on 2021-04-12 14:26 (UTC)

Hello,

A recent update seems to have created some conflicts with autokey-common and autokey-gtk if the user has pyenv installed.

In order to get around this, I cleaned up my PATH and pyenv vars temporarily:

PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

unset PYENV_ROOT
unset PYENV_SHELL
unset PYENV_VIRTUALENVWRAPPER_PYENV_VERSION

yay -Syy autokey-gtk

This seems to have worked

Ray commented on 2021-01-16 21:19 (UTC)

I just found this AUR and used it to replace old Autokey that no longer functioned. Autokey is a critical application for so many of us. I hope development will continue. Thank you for updating this package.

buzuddha commented on 2020-12-17 02:32 (UTC) (edited on 2020-12-17 02:38 (UTC) by buzuddha)

Gotcha. Was in the autokey directory. Just didn't realize I needed to add the version numbers and extension.

 $ sudo pacman -U --asdeps autokey-common-0.95.10-2-x86_64.pkg.tar.zst

seemed to do it. Same worked for for autokey-gtk.

Thanks for your help!

yochananmarqos commented on 2020-12-17 02:28 (UTC)

@buzuddha: You already built the packages, now go to the $PKGDEST and install them. Also see man makepkg and read the Arch wiki page.

buzuddha commented on 2020-12-17 02:23 (UTC)

Hmmm...

[user@Squarch autokey]$ makepkg -s
==> ERROR: The package group has already been built. (use -f to overwrite)
[user@Squarch autokey]$ sudo pacman -U --asdeps autokey-common
[sudo] password for user: 
loading packages...
error: 'autokey-common': could not find or read package

I get the same with 

makepkg -sf
and then the pacman install. Any thoughts?

yochananmarqos commented on 2020-12-17 01:55 (UTC) (edited on 2020-12-17 01:56 (UTC) by yochananmarqos)

@buzuddha: Build the package without -i, then install manually after:

sudo pacman -U --asdeps autokey-common

Then either:

sudo pacman -U autokey-gtk

Or:

sudo pacman -U autokey-qt

buzuddha commented on 2020-12-17 01:39 (UTC)

I'm having an issue with updating autokey. The long story is here: https://bbs.archlinux.org/viewtopic.php?pid=1943997#p1943997

The short story is :: autokey-gtk and autokey-qt are in conflict during makepkg -si of auotkey-common. Anything I'm missing?

yochananmarqos commented on 2020-12-16 23:07 (UTC)

@zhimsel: Good catch, fixed.

zhimsel commented on 2020-12-16 22:55 (UTC)

FYI, the PKGBUILD as-is is broken (at least on my system). All the rm commands for the pycache files need to be rm -f. Those file don't exist (on my system), so the plain rm command fails.

https://gist.github.com/zhimsel/2c794f552d19e175f7fb8f5854cfa85e

yochananmarqos commented on 2020-12-12 15:13 (UTC)

PSA: You may need to uninstall the old autokey package before you can upgrade to autokey-common + autokey-gtk / autokey-qt due to conflicting files.

ectospasm commented on 2020-12-09 04:28 (UTC)

It looks like Arch pushed out a new version of Python (3.9). I ran into errors running autokey-gtk and autokey-qt, because the Python module autokey was not found. My AUR helper (pikaur) does not rebuild AUR packages when this happens (not sure if that's just the default pikaur configuration or I have it configured not to rebuild). I had to install the PKGBUILD manually to workaround it.

I probably could have fixed it by telling pikaur to rebuild the PKGBUILD, instead of running makepkg -sri in the directory where the PKGBUILD lives. Just a gotcha that seems to be hitting a lot of my Python programs lately.

ectospasm commented on 2020-12-04 02:58 (UTC) (edited on 2020-12-09 04:24 (UTC) by ectospasm)

@F-D: What makes you think we can support you here? Either consult your non-Arch OS's forums/bug trackers (Manjaro is NOT Arch!), or seek help from upstream.

The phrase "patched as well as non-patched" has no relevance here. What have you patched? What patch(es) did you apply? Since you don't use Arch we can't help you, as we know nothing of the customization Manjaro has introduced when you installed it. Would you go to Debian to get help with Ubuntu? Would you go to Gentoo to get help with Sabayon? Would you go to Red Hat to get help with Fedora, or CentOS? The answer should be,"No." If your chosen OS's forums/bug tracker is useless or dead, pick a better Linux distribution, or go upstream to get help.

EDIT: Oh, I see. There are two AUR packages for autokey: autokey (this page), and autokey-patched. You're still barking up the wrong tree, Manjaro is NOT Arch. See https://wiki.archlinux.org/index.php/Code_of_conduct#Arch_Linux_distribution_support_ONLY in the Arch Linux Code of Conduct.

properlypurple commented on 2020-12-03 10:16 (UTC)

I just copied the dependencies from the main autokey package. I'm glad it worked out :)

sebastiansam55 commented on 2020-12-02 21:16 (UTC)

This package needs to be split into Gtk and Qt versions. If you install this package and intend to use it on Qt based systems you MUST install the optional dependencies.

F-D commented on 2020-12-02 05:33 (UTC) (edited on 2020-12-02 05:35 (UTC) by F-D)

Hi I Can't use autokey on a XFCE Manjaro (patched as well as not-patched) "Error starting interface. Keyboard monitoring will be disabled. Check your system/configuraton. Can't connect to display ".0.0":b 'invalid MIT-MAGIC-COOKIE-1 key"

and after

"Fatal error strating AutoKey. 'Service' object has no attribute 'phraseRunner"

JoeSchr commented on 2020-11-29 12:50 (UTC) (edited on 2020-11-29 12:51 (UTC) by JoeSchr)

Hi, would it be possible to at this dependency:

python-qscintilla-qt5

It was missing and because of this autokey-qt wasn't working. See here: autokey/issues/475

Thanks and great work!

EDIT: Ah sorry, I just saw, it's alread in optional dependencies, sorry about that

lateparty commented on 2020-11-13 00:19 (UTC)

@yochananmarqos yes please! thank you. I feel like I'm going to see a dark saber on the Mandalorian again before I get a response from the package owner here :(

yochananmarqos commented on 2020-11-12 21:39 (UTC)

I fixed my PKGBUILD if anyone is interested.

lateparty commented on 2020-10-17 14:19 (UTC)

@dark-saber using the current version, and did a rebuild, and I am still experiencing Traceback issues when opening autokey-qt from the terminal.

yochananmarqos commented on 2019-12-06 19:11 (UTC)

@dark-saber: I've updated my split-package PKGBUILD. It's actually proper this time and mimics the contents of the Debian packages of the same names. The only way I can see to avoid duplicate / conflicting files is to remove them manually.

dark-saber commented on 2019-11-19 00:05 (UTC)

ronjouch:

Yes, I've run into that with yay. Clearing the pkgdest or using yay -S --rebuild autokey seems to do the trick for me.

ronjouch commented on 2019-11-18 02:36 (UTC)

Thanks @dark-saber.

I had rebuilt and it didn't solve the issue. I guess my AUR helper (yay) must maintain a cache and the simple rebuild I did must have failed to bust its cache.

Anyway, problem addressed with 0.95.8-2 :)

dark-saber commented on 2019-11-17 23:48 (UTC)

Thanks, ectospasm.

Yeah, usually you have to rebuild all foreign (AUR) python packages after major python upgrades. pacman -Qqm may be helpful.

I've bumped the pkgrel to make sure everyone has rebuilt the package, but if I understand it correctly the philosophy of AUR is it's a user's responsibility to rebuild packages after the updates of their dependencies.

ectospasm commented on 2019-11-17 23:31 (UTC)

I changed directory to ~/.local/share/pikaur/aur_repos/autokey, and ran makepkg -sri to rebuild the package. That worked. This upstream issue defines the problem @ronjouch and I were getting:

https://github.com/autokey/autokey/issues/323

Make sure you rebuild the package. Apparently my AUR helper (pikaur) wasn't doing that properly after the change to Python3.8.

ronjouch commented on 2019-11-17 19:12 (UTC)

Same issue as user ectospasm since Arch's Python 3.8 upgrade. Re-building the package from PKGBUILD does not address the issue.

13:57:47 ~ autokey-gtk
Traceback (most recent call last):
  File "/usr/bin/autokey-gtk", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'autokey==0.95.7' distribution was not found and is required by the application

ectospasm commented on 2019-11-17 02:31 (UTC) (edited on 2019-11-17 02:32 (UTC) by ectospasm)

I'm getting a traceback when launching autokey-gtk:

Traceback (most recent call last):

File "/usr/bin/autokey-gtk", line 6, in <module>
   from pkg_resources import load_entry_point
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in <module>
  def _initialize_master_working_set():
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside
  f(*args, **kwargs)
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set
  working_set = WorkingSet._build_master()
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master
  ws.require(__requires__)
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require
  needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve
  raise DistributionNotFound(req, requirers)

yochananmarqos commented on 2019-11-11 18:01 (UTC)

@Dr-Bracket: You're missing python-qscintilla-qt5.

dginovker commented on 2019-11-11 17:58 (UTC)

dark-saber, I don't quite understand your comment on how you fix autokey-qt. What packages should I additionally install to fix the following issue?

ImportError: cannot import name 'Qsci' from 'PyQt5' (/usr/lib/python3.7/site-packages/PyQt5/__init__.py)

dark-saber commented on 2019-11-08 23:48 (UTC)

yochananmarqos:

Thank you! I guess most of this should be fixed now.

python-setuptools was moved to deps per fzzy's report on 2019-07-20 07:31.

I'll look into splitting the package slightly later, I wanted to do it for long enough, but the last time I've tried to do that it appeared to be less trivial than I expected.

yochananmarqos commented on 2019-11-05 20:51 (UTC) (edited on 2019-11-05 20:54 (UTC) by yochananmarqos)

@dark-saber: Why not create a split package? autokey-common as base and autokey-gtk / autokey-qt as meta packages with the corresponding dependencies? See my preliminary PKGBUILD.

FYI, python-six is not necessary as it's required by python-xlib. Same with hicolor-icon-theme, gtk-update-icon-cache requires it.

It appears qt5-svg is missing, see here.

dark-saber commented on 2019-10-07 10:59 (UTC)

FrederickZh:

python-qscintilla-qt5 is in optdeps. That's not ideal, because it requires the manual intervention if you need autokey-qt, but it's only one time. The main problem is the main GUI of autokey is GTK, it was built around it initially, and Qt support was broken for prolonged time and restored only recently. And we can create a separate autokey-qt package, but the only difference it would have the Qt optdeps becoming deps; I guess, we won't be able to remove any of the GTK deps.

FrederickZh commented on 2019-10-06 15:41 (UTC)

It seems that autokey-qt needs python-qscintilla-qt5 to run. Otherwise it exits with an ImportError: cannot import name 'Qsci' from 'PyQt5' (/usr/lib/python3.7/site-packages/PyQt5/__init__.py) error.

dark-saber commented on 2019-07-21 12:11 (UTC)

fzzy: Fixed, thank you!

fzzy commented on 2019-07-20 02:31 (UTC)

the package is missing a dependency: extra/python-setuptools

resulting in error:

Traceback (most recent call last): File "/usr/bin/autokey-gtk", line 6, in <module> from pkg_resources import load_entry_point ModuleNotFoundError: No module named 'pkg_resources'

dark-saber commented on 2019-05-01 21:13 (UTC)

ectospasm: For monitoring I'm just using the Update Scanner extension for Firefox for now. That's not ideal, I wanted to switch to something better, but too many projects are not on Github (yet? I see a certain trend), so I end up monitoring some random page with a changelog. For GitHub projects, I have some ugly script that downloads the latest release from Releases page, tries to build it and runs namcap, but that doesn't always work, sometimes people change the base filename or compression method over releases, sometimes they publish the latest releases not on GitHub, but in other places for whatever reason. Then I'm looking through the changelog and run the app (or app that uses the library) manually to check if it's broken, unless that's some minor release of a Python/Ruby library.

ectospasm commented on 2019-04-30 23:36 (UTC)

dark-saber: Nope, I missed something. In all the hubbub I had forgotten that I actually uninstalled the AUR package (the setup.py install method won't work otherwise). When I didn't see the update come across in my (pikaur) package list, I was alarmed and thought it hadn't updated. Hence my message.

I guess you have a script that polls GitHub for a new release so it builds automatically? Just curious on how that works.

dark-saber commented on 2019-04-30 11:30 (UTC)

ectospasm: The package was updated to 0.95.7 two hours before your comment. Did I miss something?

ectospasm commented on 2019-04-29 21:36 (UTC)

Version 0.95.7 was released by the upstream developer TODAY (2019-04-29). Please update the AUR accordingly, it contains a fix I need (bugfixes/issue_257).

ectospasm commented on 2019-02-12 02:35 (UTC) (edited on 2019-02-12 02:45 (UTC) by ectospasm)

This package should be renamed to autokey, as autokey-py3 has been merged upstream (autokey is written in Python3 now).

Also, there is an upstream branch (https://github.com/autokey/autokey/tree/bugfix/issue_257) which fixes an Xlib.error.BadAtom error I encountered with the AUR package released 2019-02-10T10:50 -05:00. I will be eagerly awaiting for upstream to merge this fix with master. The BadAtom error breaks the X loop for autokey, rendering at least typed abbreviations useless.

The upstream developer was EXTREMELY responsive. They gave an initial response within seconds of my post, and within 24 hours the bugfix was applied to a branch. I am extremely impressed by this.

D_Schwartfeger commented on 2018-10-25 02:15 (UTC)

Information for other users of KDE/oxygen-gtk: On Manjaro KDE with GTK3 theme oxygen-gtk the 'Main Window' doesn't display properly and I have to start with something like "GTK_THEME=Adwaita:Manjaro autokey-gtk". I don't know if this a problem with oxygen-gtk or Autokey. If anyone can help I could send verbose logging info.

dark-saber commented on 2018-08-08 15:29 (UTC)

Alright, with some more patching python-atspi becomes an optional dep again.

But if you need ATSPI on Gtk interface, you still have to install the python-atspi-git package, the error messages are silenced, but the package from extra/ won't work.

dark-saber commented on 2018-08-08 15:05 (UTC)

Python-atspi is broken in Arch at the moment, see https://bugs.archlinux.org/task/59547.

The git version of python-atspi is currently the same 2.26.0 version with the added fix to the async problem from https://gitlab.gnome.org/GNOME/pyatspi2/merge_requests/3. It should replace the extra/python-atspi without major issues.

I guess we'll have to keep the current state of things till the new release of pyatspi with the fix merged or till the package in extra/ gets patched, whichever comes first.

zerophase commented on 2018-08-08 14:43 (UTC)

The issue with python-atspi is the git version needs to be released? I can't swith atspi versions as my gui needs the arch atspi. Have you tried getting the python-atspi maintainer to patch their version with the change needed?

D1ceWard commented on 2018-08-08 08:22 (UTC) (edited on 2018-08-08 08:40 (UTC) by D1ceWard)

Can't remove python-atspi since it's used for my graphical interface (cinnamon)

Package python-atspi will be removed due to a conflict with autokey-py3
:: Dependency python-atspi of package caribou is not fulfilled
:: Dependency caribou of package cinnamon is not fulfilled

But as you said Qt version work fine

DaveB commented on 2018-08-08 06:42 (UTC)

Works for me now, thanks!

dark-saber commented on 2018-08-07 17:58 (UTC)

Thanks for the reports! Yes, the package should be reinstalled after major python update like most other AUR python packages.

Regarding atspi error, I believe, this should be reported upstream. Python-atspi will be in conflicts array till the issues are resolved. autokey-qt didn't fail for me after quick testing, autokey-gtk worked too if you remove python-atspi. If you'll find some more issues, please let me know.

DaveB commented on 2018-08-07 07:28 (UTC)

After getting the same error as below (re autokey==0.95.2) and updating, I now get the following error.

File "/usr/lib/python3.7/site-packages/pyatspi/registry.py", line 114
self.async = False  # not fully supported yet
         ^
    SyntaxError: invalid syntax

prosoitos commented on 2018-08-06 23:57 (UTC) (edited on 2018-08-07 00:02 (UTC) by prosoitos)

Same here. Broke with python updates.

pkg_resources.DistributionNotFound: The 'autokey==0.95.2' distribution was not found and is required by the application

Other apps broke with the same error message.

xardover commented on 2018-08-06 20:47 (UTC)

Broke with latest python updates

Batou commented on 2018-05-12 05:41 (UTC) (edited on 2018-05-12 05:43 (UTC) by Batou)

@cmad, maintainer on the github changed some files to fix a bug. Change 1st hash to d891c446d6413954c45db8f32ab4fc0db6022f1fabf7d163350137b25a279154

cmad commented on 2018-05-11 23:15 (UTC)

I'm getting an integrity error with v0.94.0.tar.gz The sha256 doesn't seem to match for it.

wallace11 commented on 2018-04-29 17:02 (UTC)

Manjaro KDE doesn't export locale properly so in order to run autokey-gtk you must first export your locale via export LC_ALL="en_US.UTF-8"

jfk commented on 2017-12-15 23:14 (UTC)

@dark-saber: ok thank you for your reply, I'll have an eye on further developments.

dark-saber commented on 2017-12-14 06:12 (UTC)

jfk: Are you trying to run autokey-qt or autokey-gtk? Could you please try to execute autokey-gtk from the terminal and see if there is any useful output.

Autokey-qt is broken for a long time, because new versions of Plasma don't support PyKDE4, which it was based on, and PyKDE4 packages were removed from Arch repos. I see xuzhao9 is working now on PyQt5 port (https://github.com/autokey-py3/autokey/network), I hope he would make it, but for now we are stuck with GTK interface.

jfk commented on 2017-12-13 21:43 (UTC)

KDE Plasma 5.40.0 lts 4-9.68 nothing opens.

"qr-at-spi" is installed.

dark-saber commented on 2017-10-31 21:31 (UTC)

franga2000: Added it, thanks!

franga2000 commented on 2017-10-31 12:59 (UTC)

The qt-at-spi (AUR) package is required to make this work in KDE. This should probably be added to optdepends

a-bostaurus commented on 2017-10-07 08:30 (UTC)

Thank you. I did as you proposed. Some years ago I had this problems, too.

dark-saber commented on 2017-10-04 07:21 (UTC) (edited on 2017-10-04 07:26 (UTC) by dark-saber)

I'm just maintaining the package for Arch and I'm capable to solve packaging problems mostly (missed dependencies, that kind of stuff). Your issue should be addressed to developers: https://github.com/autokey-py3/autokey/issues. Here's the problem reporting guide: https://github.com/autokey/autokey/wiki/Problem-Reporting-Guide, it would be better to run autokey via "autokey-gtk -l" and attach the logs. By the way, I'm on kernel 4.13.4 / XFCE / nvidia, and abbreviations seemingly work for me.

a-bostaurus commented on 2017-10-04 07:05 (UTC)

What does that mean: "This should probably be reported upstream." How can I do this?

a-bostaurus commented on 2017-09-25 06:05 (UTC)

I think the working of autokey depends not only on kernel 4.12 or 4.13 but also on the graphic utilities. My desktop computer is with intel: Autokey is okay with 4.13. My notebook is with nvidia; autokey does not work with 4.13.

dark-saber commented on 2017-09-22 11:03 (UTC)

a-bostaurus: This should probably be reported upstream. I've tried it on Arch Linux testing now (Linux 4.13.3, XFCE) and, although I've ran into some other problems (pasting using Mouse Selection just hangs; no non-latin input using Keyboard method; phrase list doesn't refresh automatically after modifying it using scripts, had to restart the app to refresh), I guess I didn't encounter yours. I've found the only issue that might be remotely related to yours: https://github.com/autokey-py3/autokey/issues/95 There may be something in the debug logs too.

a-bostaurus commented on 2017-09-22 08:17 (UTC) (edited on 2017-09-22 08:22 (UTC) by a-bostaurus)

autokey does not work after the last update of Manjaro stable Kernel 4.13) with Mate and XFCE. The abbreviations are not changed into the extended epressions. I cannot see any reason for this behaviour. I tried kernel 4.12, too. With this it works.

dark-saber commented on 2017-02-23 06:49 (UTC)

Fixed, thanks!

elbowz commented on 2017-02-22 13:07 (UTC)

I get this error: Autokey needs setuptools in order to build. Install it with your packagemanager (python-setuptools) or via pip (pip install setuptools) adding python-setuptools to dependencies solve the issue

dark-saber commented on 2017-01-14 15:20 (UTC)

The recent problems were introduced by this commit: https://github.com/autokey-py3/autokey/commit/2250d90d31aec0fac029ea2f9c2f1c71cfd09daf and in fact they consist of two parts: 1. 'python3-xlib' in Ubuntu is 'python-xlib' in Arch, this patches easily. 2. 'dbus-python' is somehow not found in Arch, even if python-dbus and python-dbus-common are installed. Other aliases, like 'dbus', 'python-dbus' etc. don't work too. I just patched this dep out of setup.py, especially since we still control dependencies by our distribution tools. But I still wonder what's wrong with python-dbus, some people had the same problem with blockify (https://aur.archlinux.org/packages/blockify/?comments=all), but that was resolved when this dep was removed from upstream. pip install would work, of course, but using that we're mixing Arch and python's package managers, and get all kinds of problems on further updates/removes. It would be wiser to just install autokey via pip if we're going this way.

Hal5000 commented on 2017-01-13 09:34 (UTC)

I was able to fix this problem by installing python3-xlib using pip: sudo pip install python3-xlib

ronjouch commented on 2017-01-12 22:55 (UTC) (edited on 2017-01-12 23:35 (UTC) by ronjouch)

@dark-saber: version 0.93.9-1 builds successfully but fails at runtime with an exception on python3-xlib (0.93.7-1 worked fine). Sadly, your suggestion below to @snuffop didn't work for me; here is what I tried and I still get the same exception: sudo pacman -R python-xlib autokey-py3 && sudo pacman -S python-xlib && yaourt -S autokey-py3 -------- Traceback (most recent call last): File "/usr/bin/autokey-gtk", line 6, in <module> from pkg_resources import load_entry_point File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3019, in <module> @_call_aside File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 655, in _build_master ws.require(__requires__) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 963, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 849, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'python3-xlib' distribution was not found and is required by autokey -------- ... even though python-xlib is installed: ~ sudo pacman -Syu python-xlib :: Synchronizing package databases... core is up to date extra is up to date community is up to date multilib is up to date warning: python-xlib-0.18-2 is up to date -- reinstalling :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... Packages (1) python-xlib-0.18-2 Total Installed Size: 0.76 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] y (1/1) checking keys in keyring [##############################] 100% (1/1) checking package integrity [##############################] 100% (1/1) loading package files [##############################] 100% (1/1) checking for file conflicts [##############################] 100% (1/1) checking available disk space [##############################] 100% :: Processing package changes... (1/1) reinstalling python-xlib [##############################] 100%

snuffop commented on 2017-01-12 17:46 (UTC) (edited on 2017-01-12 17:47 (UTC) by snuffop)

I've re installed all pkgs built against 3.5 as well as xlib and autokey-py3 same error and trace.  pacman -Qo /usr/lib/python3.5 error: No package owns /usr/lib/python3.5

dark-saber commented on 2017-01-12 15:30 (UTC)

troxor: Thank you for maintaining the upstream! Yes, this package now defaults to GTK frontend, all GTK optdepends became mandatory. Qt optdepends will still be included in PKGBUILD for some time while mentioning their deprecated status in case someone will be able to use this frontend, however, I cannot run it anymore even with kdebindings-python-git (I guess, after the recent update to python 3.6). snuffop: python-* means python3-* in Arch. I've had similar problems with different python packages after recent python 3.6 upgrade. Here (https://aur.archlinux.org/packages/caffeine-ng/?comments=all) it is suggested to remove, then reinstall the conflicting package, and then rebuild autokey-py3. Something like this: sudo pacman -R python-xlib autokey-py3 && sudo pacman -S python-xlib && pacaur (or yaourt, or whatever) -S autokey-py3 could probably work.

snuffop commented on 2017-01-12 14:15 (UTC)

Today after Update I'm getting this trace on startup raceback (most recent call last): File "/usr/bin/autokey-gtk", line 6, in <module> from pkg_resources import load_entry_point File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3019, in <module> @_call_aside File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 655, in _build_master ws.require(__requires__) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 963, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 849, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'python3-xlib' distribution was not found and is required by autokey python-xlib and python2-xlib are installed I'm not catching the reference to python3-xlib? What am I missing?

troxor commented on 2017-01-05 17:51 (UTC)

I've picked up the torch of trying to maintain autokey-py3 upstream at https://github.com/autokey-py3/autokey. When trying to reproduce a bug, I encountered the missing kdebindings-python issue on Arch. In the meantime, a couple suggestions here: - Update the links to tarball (github release tarball) and - patch out the KDE/Qt Frontend and use just the GTK frontend in the meantime Thanks to dark-saber for maintaining this PKGBUILD!

nfs commented on 2016-12-30 03:40 (UTC)

After thinking about it a while, I reckon I'll wait till this is resolved upstream and there is something newer than now-deprecated pykde4. Are you going to report it upstream? Frankly, I'm not sure precisely what to report to whom. . .

dark-saber commented on 2016-12-26 19:13 (UTC)

Have you seen this topic: https://bbs.archlinux.org/viewtopic.php?id=203480? More specifically, could you check the output of these commands: $ which python $ python -c "import gi; print(gi.__spec__)" to make sure that the path to the module is /usr/lib/python3.5/site-packages/gi?

ant commented on 2016-12-26 16:48 (UTC)

Does not run. Installing python-gobject or python-gobject2 did not help: $ autokey-gtk installed with “pip install -e” Traceback (most recent call last): File "/usr/bin/autokey-gtk", line 28, in <module> from autokey.gtkapp import Application File "/usr/lib/python3.5/site-packages/autokey/gtkapp.py", line 24, in <module> from gi.repository import Gtk, Gdk, GObject, GLib ImportError: No module named 'gi.repository' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/autokey-gtk", line 31, in <module> from src.lib.gtkapp import Application ImportError: No module named 'src'

nfs commented on 2016-12-24 18:29 (UTC) (edited on 2016-12-30 03:40 (UTC) by nfs)

Thanks for clarifying. . .

dark-saber commented on 2016-12-24 14:09 (UTC)

The problem here, as far as I can see, is that KDE is dropping Qt4 support (https://wiki.debian.org/Qt4WebKitRemoval), unfortunately, including pykde4, on which autokey-qt is based. So the temporary solution is installing kdebindings-python-common and kdebindings-python from Arch Linux Archive (https://archive.archlinux.org/packages/k/kdebindings-python-common/kdebindings-python-common-4.14.3-7-x86_64.pkg.tar.xz, https://archive.archlinux.org/packages/k/kdebindings-python/kdebindings-python-4.14.3-7-x86_64.pkg.tar.xz) - for now it works. But I guess this should be reported upstream, and the upstream should eventually move on to something newer than now-deprecated pykde4.

nfs commented on 2016-12-23 17:44 (UTC)

Could you give us an indication as to when you might be able to find the time to resolve this? I'm not trying to rush you. I understand this is a busy time of the year for many of us, and it may take you a while to get around to it. I'm just wondering how often to check back here.

dark-saber commented on 2016-12-22 07:58 (UTC) (edited on 2016-12-23 16:43 (UTC) by dark-saber)

So, I guess the problem here is that kdebindings-python were recently removed from [extra], and the new extra/kross-interpreters package does not provide the necessary bindings, at least not for python3. I'll look more into it, but for now autokey-qt is broken indeed.

nfs commented on 2016-12-21 20:17 (UTC) (edited on 2016-12-22 15:01 (UTC) by nfs)

Hi, Yes, they were already installed. Here is the output when I re-ran the installations, in case it reveals anything. I did not actually reinstall them but verified they were up to date: warning: kdebindings-python-git-r18.7679bd2-1 is up to date -- reinstalling warning: kdebindings-python2-git-r18.7679bd2-1 is up to date -- reinstalling warning: kdebindings-python-common-git-r18.7679bd2-1 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Packages (3) kdebindings-python-common-git-r18.7679bd2-1 kdebindings-python-git-r18.7679bd2-1 kdebindings-python2-git-r18.7679bd2-1 Total Installed Size: 6.97 MiB Net Upgrade Size: 0.00 MiB warning: python-qscintilla-qt4-2.9.3-1 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Packages (1) python-qscintilla-qt4-2.9.3-1 Total Installed Size: 1.33 MiB Net Upgrade Size: 0.00 MiB

dark-saber commented on 2016-12-21 09:38 (UTC)

nfs: Do you have all optdepends required for autokey-qt (python-qscintilla, kdebindings-python) installed too?

nfs commented on 2016-12-21 08:36 (UTC)

I believe I've installed all the dependencies, but I am getting the following response from autokey-qt: Traceback (most recent call last): File "/usr/bin/autokey-qt", line 54, in <module> from autokey.qtapp import Application File "/usr/lib/python3.5/site-packages/autokey/qtapp.py", line 23, in <module> from PyKDE4.kdecore import KCmdLineArgs, KCmdLineOptions, KAboutData, ki18n, i18n ImportError: No module named 'PyKDE4' Any suggestions?

dark-saber commented on 2016-10-28 07:35 (UTC)

@sdothum: I guess it's just a warning, and it shouldn't cripple the functionality of the application, it just makes some spam in the terminal. I see you have already reported that upstream, that is great. Probably it can be fixed similar to this: https://github.com/neovim/python-gui/pull/19/commits/16e20590aac7e44772cfe0b4eeaaab275f81f88e

sdothum commented on 2016-10-27 01:35 (UTC)

autokey-gtk issues this message: /usr/lib/python3.5/site-packages/autokey/gtkapp.py:24: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.

elbowz commented on 2016-09-12 16:20 (UTC)

Thanks!! Works like a charm now

dark-saber commented on 2016-09-10 21:07 (UTC)

@elbowz: You have to install python-qscintilla and kdebindings-python from optdepends for autokey-qt to work. I didn't include them (and their GTK counterparts) in mandatory dependencies list, so people who use only GTK don't have to install a lot of Qt libraries and vice versa.

elbowz commented on 2016-09-08 11:03 (UTC)

Thanks for your package and work. When I try to start it, I get: ImportError: No module named 'dbus.mainloop.qt' I have already installed: python-dbus

dark-saber commented on 2016-08-14 18:13 (UTC)

I know that the new version was released, but I cannot push the changed PKGBUILD because AUR is broken from 2016-08-14 06:00.

cryzed commented on 2016-08-12 13:42 (UTC)

If someone is as reliant on the abbreviation (hotstrings) functionality as I am, I made this: https://github.com/cryzed/bin/#hotstrings in case AutoKey-py3 should ever stop working.

cryzed commented on 2016-08-10 18:58 (UTC) (edited on 2016-08-10 19:07 (UTC) by cryzed)

@dark-saber: Awesome, thanks for your feedback and efforts. You've probably already seen that I suggested to the AUR python-xlib maintainer to rename the package, but so far no answer. If more comments keep cropping up that complain about AutoKey being broken, forking the package might be better sooner than later. Although you have to consider conflicts between the official python-xlib package and the one from the AUR then -- since they will use the same paths. EDIT: One of the worse bugs in the RECORD extension module in the official python-xlib release was just fixed, causing AutoKey-py3 to at least start and run successfully. Unfortunately it seems that sending keys using the Keyboard mode has changed slightly: the abbreviation is substituted with an empty string and not the actual replacement. On the surface it seems like making AutoKey-py3 work with the official release shouldn't be too much work, but I'm not familiar enough with its code to tell accurately.

dark-saber commented on 2016-08-10 13:22 (UTC)

@cryzed: That's great you've reported it upstream. I see that installing aur/python-xlib fixes the problem. Now I'm just waiting for the renaming of aur/python-xlib (or fixing the isuue upstream). If it won't happen after some time, I can fork the aur package with different name, but I guess this won't be necessary.

cryzed commented on 2016-08-08 20:54 (UTC) (edited on 2016-08-08 21:59 (UTC) by cryzed)

The update to python-xlib 0.16-1 seems to have broken phrase insertion for me. It seems like the entered abbreviation isn't properly recognized anymore. When manually starting autokey-qt from the console, the following traceback is shown: https://gist.github.com/anonymous/c3d3347ffda73d1c7b69950d4c5adb69. Here is the issue on GitHub: https://github.com/guoci/autokey-py3/issues/33. EDIT: This seems to have happened because the python-xlib package in the official repositories has been updated to 0.16, which is a new release compatible with Python 3, without LiuLang's patches: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/python-xlib&id=4df4fbfd2d68d77e908a06348df1cdbe605b758b.

cryzed commented on 2016-06-18 12:27 (UTC)

This is great, thank you so much for maintaining it! I could be wrong, but I think the change suggested by @D_Schwartfeger fixed missing controls in the KDE GUI -- previously I had to rely solely on shortcuts and available context actions; I wasn't even aware that something was missing.

dark-saber commented on 2016-06-18 08:00 (UTC)

Fixed, thanks!

D_Schwartfeger commented on 2016-06-17 21:41 (UTC)

I don't know what other arch distributions are like but on Manjaro KDE I had to shift the 'autokey' folder from '/usr/share/kde4/apps/' to '/usr/share/apps/' to get the autokey-qt main window to show all the editing and config options. Without doing this it complained of not being able to find 'autokeyui.rc' which is in this folder. Does this need and extra post install step added to the package for arch in general? Hopefully it may help others to get it working anyway.

dark-saber commented on 2016-05-22 06:27 (UTC)

Fixed, thank you!

MagicAndWires commented on 2016-05-20 22:54 (UTC)

python-pip is not needed as a dependency; it's used for installing python packages, which in this case can be all installed through the Arch repositories or AUR.

ectospasm commented on 2016-04-23 12:47 (UTC)

This package fails for me if I install it through AUR. It was working, I don't know what changed (some Python library, probably python-xlib). Now when I run it with autokey-gtk --verbose, I see it gets stuck in the main X loop, with a bunch of messages regarding Xlib.error.BadAtom: 2016-04-23 07:25:07,537 ERROR - interface - Error in X event loop thread Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/autokey/interface.py", line 116, in __eventLoop method(*args) File "/usr/lib/python3.5/site-packages/autokey/interface.py", line 329, in __grabHotkeysForWindow title = self.get_window_title(window) File "/usr/lib/python3.5/site-packages/autokey/interface.py", line 947, in get_window_title return self.__getWinTitle(windowvar, traverse) File "/usr/lib/python3.5/site-packages/autokey/interface.py", line 961, in __getWinTitle atom = windowvar.get_property(self.__VisibleNameAtom, 0, 0, 255) File "/usr/lib/python3.5/site-packages/Xlib/xobject/drawable.py", line 441, in get_property long_length = length) File "/usr/lib/python3.5/site-packages/Xlib/protocol/rq.py", line 1481, in __init__ self.reply() File "/usr/lib/python3.5/site-packages/Xlib/protocol/rq.py", line 1501, in reply raise self._error Xlib.error.BadAtom: <class 'Xlib.error.BadAtom'>: code = 5, resource_id = 0, sequence_number = 84, major_opcode = 20, minor_opcode = 0 It repeats this for every event autokey captures. And while it traps events it should respond to, the error means it can't do anything with them. I have not had the time to track this down, and googling doesn't present me a solution. If I install straight from the upstream git repository (which I've had to do to develop some patches to autokey-py3), everything is fine, no Xlib.error.BadAtom messages (and my autokey scripts actually work as expected). I haven't had time to inspect the differences between the upstream version and the AUR package. I'd prefer installing the AUR package because then it's manageable with yaourt.

flyhunter commented on 2015-12-29 20:56 (UTC) (edited on 2016-01-03 21:05 (UTC) by flyhunter)

[Solved, see edit] I can't start this application. I have all the dependencies (including the optional ones) and I'm getting this error: “Error starting interface. Keyboard monitoring will be disabled. Check your system/configuration.”. The detailed error reads “~/.Xauthority: [Errno 2] No such file or directory: '/home/user/.Xauthority'”. I've added “export XAUTHORITY=/home/user/.Xauthority” to /etc/profile and the error remains. I'm running XFCE4 DE. Can anyone help me, please? Edit: "touch ~/.Xauthority" did the trick.

dark-saber commented on 2015-11-24 16:29 (UTC)

Updated, thank you!

DaveB commented on 2015-11-23 20:21 (UTC)

Hey, you might want to add an autokey-py3.install that would look something like this: post_install() { gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor } post_remove() { post_install } and adding: install=${pkgname}.install in the declarations in your PKGBUILD. That would take care of the icon not showing up after an install.

nhasian commented on 2015-07-29 23:12 (UTC)

after manually installing a few of the missing dependencies (python-pip and python-xlib) this Python3 port of autokey works great! unlike autokey-gtk which currently is not functioning unfortunately.