logoalt Hacker News

nilslindemanntoday at 6:28 PM1 replyview on HN

> GUI automation is fairly alien and roundabout way of doing things on Mac and Linux.

That's a nice claim you just made up there, out of thin air.

> If you have something specific in mind, you can say it.

I need something to hack together a solution and then go on. I don't want to

* Create GitHub issues and hope and then wait.

* Learn how this GUI was written and fix it by modifying and compiling the source.

What I need is the ability to:

* Activate windows

* Detect the active window

* Move and rescale the active window

* Move the mouse relative to the active window

* Move the mouse absolutely to the screen (if the relative method is broken)

* Sometimes move the mouse relative to itself

* Press mouse buttons, including WheelUp, and WheelDown (and that is sent to the active window)

* press keyboard button combinations (and that is sent to the active window)

* Send text (yep, many tools can do that)

* activate menu entries in the active window

* Get the text of active menu entries in the active window

* Find icons in the active window by providing an image, rarely used, when all above attempts fail.

* Finally, define shortcuts that do combined actions of the above.

I won't walk with you through every concrete possible application, but I give an example for Scid, which is also a Linux tool. Both on Windows and Linux, it happens that the save game dialog is partly moved outside the view rectangle of my screen. No idea why that is so. I need to drag the save dialog to the middle of the screen first. AutoHotkey to the rescue:

    #HotIf exe_active("scid")  ; `exe_active` is a shortcut
    
        ^s:: {
            Send("^+s")
            WinWait("Scid: Partie speichern...")
            WinMove(19, 95, 660, 651)  ; place it over the board.
        }
        
        ; ...
    
    #HotIf

Another example. Every window manager I tested, which has "snap window to border in order to place it on half the screen" does not restore the window to full screen when I press the button left of the "close window" button. Instead, they place the window in a random position. It is not "click the middle button twice to switch between full screen and snapped position", which is the common use case. Thanks to AutoHotkey, there is a fix available on Windows: https://github.com/RamonUnch/AltSnap Edit: Okay, thats not AutoHotkey but raw C. But still that would be a use case for AutoHotkey.

I hope I’ve managed to clarify my point regarding the need for an AutoHotkey on Linux. There are simply too many bugs, idiots, and unimplemented features to get back into the flow quickly without AutoHotkey.

Just when sending this text, noticing that this site does not properly handle markdown bullet list, I found another great use case for Autohotkey, when pressing the Enter key on Hacker News ...


Replies

orbital-decaytoday at 7:24 PM

Window manipulation is trivial, most window managers are even natively programmable or at least support complex rulesets that don't need scripting for such basic tasks, I'm automating KWin in a similar manner for example.

There's a myriad of tools for blind input macros.

DE manipulation is generally done with DBus and CLI tools.

UI element manipulation (menus, icons, widgets) is done through a11y, with things like accerciser, dogtail, etc. AT-SPI makes it unified.

Providing an image... do you mean OCR? Use SikuliX, however that's just a Rube Goldberg machine like way to do things if you ask me. Not if deep UI automation to fix things is any better, though.

And of course you can script all that in any industry standard scripting language instead of janky DSLs.

>Just when sending this text, noticing that this site does not properly handle markdown bullet list, I found another great use case for Autohotkey, when pressing the Enter key on Hacker News ...

I think that's easier done with a userscript.