4 ms·

> everything it does is done in different ways in other systems. You are not the first Linux user claiming that to me, but it is not true. you never actually t

> everything it does is done in different ways in other systems. You are not the first Linux user claiming that to me, but it is not true. you never actually tried, admit it. > TC can be run on Wine absolutely everywhere I just tried again on Linux Mint. The folder tabs overlay the path to the current dir and the window can just be full screen. Those are the bugs detected after a minute of usage. > DoubleCommander is a near-direct replacement Okay, I was just able to install that, and it seems to have what I need. So thats a valid Point, Linux has something comparable to Total Commander. > Log in as Administrator (...) Sure, it's trivial Yes it is, I just did that. I give you that.

orbital-decay 22d ago
Well, since you never even said what AHK feature you need it's impossible to suggest anything. Yes I used to use AHK years ago, but GUI automation is fairly alien and roundabout way of doing things on Mac and Linux. That's why I can't think of anything special about it. GUI-blind input automation and macros? There's maybe a dozen different utilities for this on every OS. If you have something specific in mind, you can say it.
- nilslindemann 22d ago
  > 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 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 ...
  - orbital-decay 22d ago
    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.
    - nilslindemann 22d ago
      Thank you, dick from the internet, for these links, which are not as relevant as you think they are. I will prefer my yanky, well-documented DSL. I think you are right with the userscript.
  - kasabali 21d ago
    xdotool and wmctrl is what you need
    - nilslindemann 21d ago
      Interesting, but isn't Wayland the future? Edit: I see it links to alternatives to that, like ydotool and dotool. But these do not seem to be active, well documented projects. Far away from the usability of AutoHotkey.

orbital-decay 22d ago

Well, since you never even said what AHK feature you need it's impossible to suggest anything. Yes I used to use AHK years ago, but GUI automation is fairly alien and roundabout way of doing things on Mac and Linux. That's why I can't think of anything special about it. GUI-blind input automation and macros? There's maybe a dozen different utilities for this on every OS. If you have something specific in mind, you can say it.

nilslindemann 22d ago
> 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 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 ...
- orbital-decay 22d ago
  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.
  - nilslindemann 22d ago
    Thank you, dick from the internet, for these links, which are not as relevant as you think they are. I will prefer my yanky, well-documented DSL. I think you are right with the userscript.
- kasabali 21d ago
  xdotool and wmctrl is what you need
  - nilslindemann 21d ago
    Interesting, but isn't Wayland the future? Edit: I see it links to alternatives to that, like ydotool and dotool. But these do not seem to be active, well documented projects. Far away from the usability of AutoHotkey.