Package Details: autokey-gtk 0.96.0-6

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 - GTK frontend
Upstream URL: https://github.com/autokey/autokey
Licenses: GPL-3.0-or-later
Submitter: dark-saber
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 69
Popularity: 0.021600
First Submitted: 2019-02-12 12:21 (UTC)
Last Updated: 2024-05-01 16:27 (UTC)

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 Next › Last »

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.

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 Next › Last »