Show HN: AutoHotkey for Linux (github.com)
this is the first functional reimplementation of AutoHotkey [1] for Unix-like systems, as far as I am aware. Half the commands are still missing, but everything important is done, as I have worked a lot on it over the past two months. Converting scripts into stand alone binaries is also supported. Hope this will find some adoption eventually. :-) - This implementation focuses on v1.0-like classic syntax from 2004 (!). This is a significant subset of the popular current v1.1 syntax from Windows (AHK_L). The reason this does not (yet?) target the full Windows spec is how complex it is. Notably, there's also another ongoing project which targets v2 called KeySharp [2].
If you are not aware of what AHK is, it is an easy but capable scripting language for automation and Hotkeys, and all sorts of visual things like GUIs.
If you want to learn more, there plenty of info on the repo, the docs html, and there's an active AHK Discord too, and I am personally also checking the forums and HN of course.
[1] https://www.autohotkey.com/ [2] https://bitbucket.org/mfeemster/keysharp/
188 comments
[ 3.3 ms ] story [ 217 ms ] thread> Please also check out Keysharp, a WIP fork of IronAHK, another complete rewrite of AutoHotkey in C# that tries to be compatible with multiple OSes and support modern, v2-like AHK syntax with much more features than this one. In comparison, AHK_X11 is a lot less ambitious and more compact, and Linux only.
Fascinating, lots to check out here. Thank you.
BTW this kind of work falls into poweruser tools IMO, which is an important area for cultivation of Linux Desktop focus. Traditionally in the Linux community this has been more of a distro-maintainer's support choice (offer poweruser tweaks and tools, or not) so it's always nice to see new distro-independent, non-dev-poweruser options coming into being.
You can compile it into a binary with no dependencies, so you can easily bring your script to other computers or share it. You can create a GUI to run commands rather than binding them to key patterns.
I used to use it in World of Warcraft to do things like have my character's entire skill rotation on one key (e.g. just keep pressing "1" and AHK will handle pressing the next "real" key for the sequence. Hit another key and I can reset the sequence early). And to automatically tatget myself and cast a heal when my health goes below 50%, which was done by polling a certain pixel on the screen for a specific value of red.
I actually had a way more advanced, but very buggy script I used for "multi boxing", which is when you pay for multiple accounts and play them simultaneously. I used WASD, TFGH, IJKL, for moving 3 characters simultaneously, the numpad for targeting, and ctrl/shift/alt + number-row for casting spells on any of the windows. So ctrl+2 would cast the warrior 2nd ability, shift+alt+4 would cast the druid and mage 4th ability, ctrl+shift+alt+2 would cast all character's 2nd ability, etc.
Blizzard used to be a lot more lax about macros[0], and they liked multiboxing because it was more money. I had a GM message me once to confirm I was playing all 3 and not afk botting. We chatted about AHK and how he wanted to learn to code.
[0] also the tools to detect macros were way worse back then, it might have been that they just accepted it rather than actually embracing it.
A dedicated language is nice because the syntax can be optimized for its purpose. As a teen with little coding experience, AHK was so easy to get simple ideas working. Often one easy line of code.
Some of the bigger monstrosities I wrote would have definitely been more manageable in another language, but then I'd have to handle always-active input listening, window management, emulating the keyboard and cursor, reading screen pixels, my own state machine for key chording, and so on. Or cobble together libraries (and still learn those).
Also probably the most important part, it was fun to work with and immediate. I wasn't a professional (or even good) programmer. But I had a goal in mind and AHK never made me want to quit.
1. Move cursor to the toolbar icon of an app, right click, navigate menus, and select an option (all with one keystroke).
2. Click a button in one program. Copy file. Switch to Excel. Switch to the right worksheet. Click a VBA button. Switch to another sheet. All with one keystroke.
3. With one keystroke, set certain settings in Visual Studio (via the menu) and run the debugger.
4. With a keystroke, sign out of Teams/Skype.
5. Launch screenshot program, present me with a dialog box asking for filename, and have it save the screenshot in a directory and provide me an Org-mode link to the saved file.
These are all "easy" in AHK. I never learned it well enough to do more advanced stuff.
That may be true of AutoHotKey on Windows but we're talking about a Linux port here where some of the features straight up don't work or don't add anything that didn't already exist in Linux.
> xdotool doesn't do hotkeys itself, and doesn't work well being run with hotkeys involving modifiers
It doesn't do those things because it doesn't need to on any version of KDE or Gnome (or probably anything else) since about 1998, possibly earlier though my memory gets foggy beyond that point.
> AutoHotKey also does hotstrings (Espanso is the closest Linux equivalent I know, and doesn't work as well IME)
Espanso and AHK probably suffer the same fate, given this line from the AHK for Linux Documentation:
> Hotstrings don't work in some applications. Not sure if this is fixable (help needed!). The only reliable alternative is using Hotkeys.
> app- or window-specific behaviour, and more.
You can absolutely do app- and window-specific things with xdotool. It merely requires adding some steps to detect the window or process, which is identical to AHK's approach if you're just writing scripts.
The best thing this port has going for it is that it has a great UI that people are already familiar with and in spite of its shortcomings as a port it is worth checking out.
I'd love if someone spent the time to develop something like this into a script generator for xdotool that could do things like recording mouse movements, etc.
Maybe a wayland-ized version can support hotstrings and the other warty edge cases that don't work on Linux the way they do on Windows.
It kind of makes sense then that this was made for and got popular on windows, because that OS is absolutely rife with annoying gui software written for the lowest common denominator of user.
Whenever i infrequently have to use windows I'm a bit shocked at the number of clicks you need to get anything done.
1. Press Ctrl P to get to the Print dialog 2. Scroll to "Print Using System Dialog" 3. Click on Page Setup. 4. Select 2 Pages per side. 5. Choose "Letter" for Paper Size 6. Click on "Print"
I can automate this using AHK on Windows. How would you do it on Linux? And how is running Firefox on Linux helping me any more than Windows?
How do you trigger the behavior? Is it bound to a key or is there a different way to trigger the action?
For example, I'm an emacs user and though I remember a lot of bindings, I also use heavily helm-M-x which provides fuzzy completion on command name.
For example, I may not remember all org-mode shortcuts, but I can do:
M-x org subtree
And I'll get a list of all org-mode commands on subtrees.
(I've never used AHK.)
How exactly does this work? Are you just sending a bunch of shortcuts? Or does autohotkey really understand when it reached "Print Using System Dialog" and which button has "Page Setup"?
That's like saying shellscripts prime utility seems like hacking optimizations on inefficient-for-power-users cli software. Every poweruser has always demand for automation, independent of the interface, software and OS.
> because that OS is absolutely rife with annoying gui software written for the lowest common denominator of user.
And yet, Linux is even worse in that regard.
Then there's also AHK's ease of use, which also makes it appealing to non-programmers or beginners. Every piece of logic (even loops etc) is basically encapsulated in a single-word command instruction, almost like ASM, but for humans. You create GUIs with `Gui, add, button`, maximize windows with `WinMaximize Firefox`, hotkeys with `a::MsgBox You pressed a` and so on, and all of that with basically no code. I'd recommend you take a short look at the AHK documentation, such as the intro or alphabetical list of commands. It gives you an idea of what you can do with it.
Besides, the entire language is visually oriented (and so is this implementation of mine): You create, edit, run, reload, and (optionally) compile scripts usually not by using terminal, but by context menus. This makes it far more accessible for people migrating from Windows, apart from the fact that you can apply your acquired AHK skills from Windows.
Finally, I have found that the existing Linux automation-specific tools (which mostly boils down to xdotool) are, in comparison to Windows AHK, inferior. Getting Windows-like automation functionality on Linux is quite a task. The main difference is that very often, you just don't need Window or Hotkey automation on Linux, because most programs are CLI-first, thankfully.
It shows a failure of the "Unix Way" imo. Everyone hand-rolling their homebrew combination of 20 different tools together is sometimes not the best way to go.
We can look at Docker, Kubernetes, Dropbox(etc), desktop environments, and many other things to see that people greatly value almost the complete opposite approach, within some sweet-spot.
The reason that no nontrivial popular program exists written using shell scripts is because the Unix Way of gluing together separate programs just isn't a sustainable software development methodology that leads to nontrivial useful software.
You can create simple GUIs straight from bash too - take a look at zenity (I'm aware it's not the only option BTW)
AHK would pull up file menu, export menu, select java, type jar filename, hit next, select jar file, confirm overwrite, next, next, select seal the jar, yes overwrite, click that one random dialog button that's bizarrely not hotkey selectable, type main class as 'default.java', next, confirm, click finish. Click confirm again despite finish because GUI. And bam, another JAR file ready to test.
Though not everything can be done with different development tools and AHK is a versatile swiss army knife. It can also do things like hotkey to make any window stay on top, send window resize message to a runaway or disobedient window, or be hotkey window clicks for games. I use it in stormworks to make my own shortcuts to edit / wiring / mirror buttons since they're 54 inches apart, and hopefully this all shows where AHK's versatility shines.
I did use PyUserInput/PyMouse to "play" Universal Paperclips one time on Linux. Similar, though not nearly as featured, to AHK.
https://www.tidbitsfortechs.com/2013/10/using-autohotkey-to-...
Helpful when I'm trying to send inline responses in an otherwise busy thread with multiple colors... and then I can switch back to my default blue after that with the same keystroke
For automation, xdotool is pretty good. xprop and wmctrl are not so user friendly though.
As for keyboard remapping, sxhkd is great, but finding what keys are called requires xev or something like it. xmodmap is not easy for beginners either.
At the very least you have to know what to look for. I'm not an advocate of AHK, but having all those options in the same place would be good.
It's also good to know linux has autokey (https://github.com/autokey/autokey) for the same result. The name is close, but it's a different project.
It's not compatible with autohotkey, but you can script using python. I used it to enter dates, emails and automatize dynalist.io actions.
[0] https://en.wikipedia.org/wiki/AutoKey
cross platform self-driving mouse & keyboard, can also record
https://github.com/jordansissel/xdotool
(Mind you, this would be a good deal harder to implement in Wayland, where possible at all, since Wayland is predicated around a security model where this kind of thing is deliberately not supported. You can either go with something compositor-specific, and I don’t know if this is possible for all compositors, though I get the impression that it should be possible for at least wlroots; or work more the way ydotool does, where possible, in basically providing a fake input device.)
You touched a good point. The one and only metric to measure success in software is the number of active users. However, i do not know of any statistics Xorg vs. Wayland users. Personally, i have no reason to switch away from X11. In contrary, it was and is a loyal companion now already for decades. I trust the Lindy effect that X11 will stay relevant for a very long time. So kudos for the OP for creating this!
https://wiki.archlinux.org/title/HiDPI#Xorg
If we figure out that this kind of automation is impossible on Wayland, I think it should still be possible to hook into the raw keyboard events with kbd and such, no? Requires root though.
At the moment, Wayland is used only by a minority of users, and most are still on X11. Sure, distros may often default to Wayland, yet almost no distro has switched the user's default upon upgrading.
Most users aren't new users or installing on new systems, and even for new users X is occasionally still default (e.g. every existing BSD, some KDE distros).
I estimate it's another 5 years before another new computer cycle and Wayland maturing will make X less relevant. 15-25-more years before we could even consider removing support.
I get some terrible screen tearing on X, especially when using OBS. On Wayland it's solid. With X/Wayland the best thing it can do is be invisible.
1. Not everyone knows what AutoHotkey is and what it does. I had to google it.
2. Not everyone speaks english. Diving into a description that includes words like "fault tolerant, extensible, high availability" so infuriatingly confusing.
Look the words up in a dictionary. It's ok not to know and to learn but you shouldn't expect everyone to adapt to your lack of knowledge.
Moving the field of software development is about solving more problems for people without putting a large learning curve in their way.
Yes some aspects will always require expertise but that is not an advantage.
But then again I would add (3) they're just buzzwords that don't actually tell you anything...
2. Those words aren't in the Readme so I'm a bit confused. I guess these were just examples though. I am not a native speaker either though... if you really think there's uncommon words to be found, I would welcome a PR.
One neat feature is that you can bundle a bunch of scripts with the runtime into a single file binary for easy distribution. If AutoHotkey runs on multiple operating systems, maybe combining this with cosmopolitan libc into an 'αcτµαlly pδrταblε εxεcµταblε' would let you bundle a script and use it across different OSes. That'd be pretty fun.
[1] https://github.com/tinku99/ahkx
I acknowledge the effort that OP has put into this project. And if the OP plans to use X11 for the foreseeable future, then it makes sense to target X11. But for any new project with a wide audience Wayland is a much more reasonable target.
begs the question. how come ahk can run on windows(tm) but not wayland? my understanding is that win10/11 are pretty secure.
[0]: https://github.com/symless/synergy-core/issues/4090
I've always looked for software similar for Linux but nothing comes close.
The documentation is second to none as well.
Anyway I'm really happy to see this, well done I hope it all goes well.
I have a user who has limited dexterity, and the ability to have a macro that selects/clicks on (modal?) dialogue box buttons based on their label (OK/Cancel etc.) would be a life saver for them. (A pre-determined set of keystrokes based on knowledge of the tab order would not work - this needs to be generic, based on the button text for my application.)
As things stand, I'm looking at hacking a video capture device and openCV together, but I can't help but think this must be a solved problem and I just have poor google-fu?
If PowerShell or Applescript have significantly better capabilities in this arena (or if there is an alternative tool I should be looking at, or other resources that might be useful in the quest), it would be great to hear. At the end of the day though, the end user is dev, and wants a Linux desktop.
https://support.microsoft.com/en-us/windows/windows-speech-r...
I imagine someone could use their computer almost entirely through that save things that require precise mouse usage like photo editing or video games. Even then, you can achieve rough mouse usage through their on-screen grid, so you can do some things.
http://sikulix.com/
I can only give you some technical details for ahk_x11 here. It would be ControlClick I think, here [1] is the Windows docs for it. Not present on ahk_x11 right now, I plainly don't know if it is possible yet [2]. If it is, I definitely want to have it. Other than that, I can only think of clicking on fixed coordinates, such as `MouseClick, left, 200, 300`. I haven't done `CoordMode` yet which would be rather important for that, out of sheer prioritization. For a generic solution, there's also ImageSearch [3] for more recent Windows AHK versions which I'd like to have at some point too. Some OCR command would be cool as well.
This will all take a while though, if nobody else joins in.
Thanks for your viewpoints though, I agree with the sibling comment that these insights are valuable.
[1] https://www.autohotkey.com/docs/commands/ControlClick.htm [2] https://github.com/phil294/AHK_X11/issues/3 [3] https://www.autohotkey.com/docs/commands/ImageSearch.htm
Yes, this is called a11y (accessibility). Install at-spi, run xwininfo, dogtail/sniff, accerciser, qdbusviewer to find dialogues and buttons, use any of the desktop automation tools to press them.
> buttons based on their label (OK/Cancel etc.)
That only works for English. Automate based on the type, not the label.
The point around internationalisation is well made. To be clear, I'm looking to implement a generic solution that potentially works for any application on the desktop. I do not have the source code for the underlying applications, so I'm not sure how/if I can discover the button type 'externally'? A config file per-application would be acceptable, though, and could address the language related issues, especially as they could then potentially be crowd-sourced.
Apologies for the hijack, but this thread feels like the right place to ask.
I have used AHK a lot and looked for a Linux alternative in the past, like AutoKey, Actiona... which did not felt as good
But nowadays I think I prefer the "Linux way" tools, the bulk can be done with: sxhkd, bash, zenity, xdotool, expanso...
AHK is all-in-one personal automation tool, very useful in Windows, a single tool with a unified language
Linux has a CLI tool for everything, more disperse, different implementations, but easier to re-use modules elsewhere
Still choice is good
Half of these crap can be solved with xdotool/wmctrl and some scripts. Everything else it's maked to be scripted. Cron, package managers, X11 events, notifications...
One guy posted here an smart automation menu sequence to create a jar from a class within Eclipse. Any competent Unix programmer would create that for Scite, Gvim, Emacs or whatevers with an external script (man java and man javac, FFS) in seconds.
---
Keyboard layout:
my whole keyboard layout used to be a remapping with AHK :)
not done by me though and the new implementation of the layout is something else (https://www.neo-layout.org/)
---
Complicated Shortcuts:
I still use it for generating and filling site specific mail addresses with a shortcut. My keyboard types "shortcut_site_specific_mailaddress" and ahk replaces it with news.ycombinator.com+is_allowed_to_pass_catch_all@mydomain.com.
For some time it was also the one tool that could dim my dell desktop screen by hotkeys with some shady dll someone provided.
---
Usability:
I also used it for alt+drag for a while (but now have a more native tool with exactly that name).
Capslock lights up if I am not in my native input language
---
Stress Relieve:
When mobile testing a lot in the emulator I got slight inflammation from clicking the mouse too much. If that happens I remap the left mouse key to the keyboard.
(Never used AHK myself but the couple times I looked for something similar to BetterTouchTool on Windows I got recommended AHK)
[1] Including support for all buttons on n-button mice for all values of n supported by USB standards, something that, last I checked, Windows itself was incapable of handling at the driver level without dropping down to low-level HID event processing that's a bit of a stretch, though not technically impossible, for AHK.
This, incidentally, is why many-buttoned Logitech gaming mice come preconfigured to send keyboard events for all but the first few buttons.
[1]https://github.com/yqrashawn/GokuRakuJoudo