AutoHotkey Community

I have a GUI that has a bunch of buttons that perform dozens of macros. I want to make it cross platform.

Since AHK can't work with Mac AND I want a more powerful, visually-pleasing, customizable GUI, I was thinking about designing a GUI in another language (like Python) that could be cross-platform.

Because I already have a nice database (several thousand lines) of functions (macros) in AHK, is there SOME WAY to call upon these with / without AHK installed when a specific button is pressed?

Ultimately, if I had a GUI already, the macros themselves could be performed in AHK for Windows and AppleScript or Quickeys or something in Mac.

I'm pretty novice with coding obviously but maybe there are some good ideas out there already for this. Or maybe I'm just ignorant and this is flawed by design. Tell me!

Ahk is windows only. I think you have to try something else... :/

joedf wrote:Ahk is windows only. I think you have to try something else... :/

There was more to my post than the first line...

Of course, you can program a GUI in another language to start AHK and other scripts. But how you run a script from a python GUI (what is surely possible) is rather a question for a python forum, isn't it?

Without AHK installed, you would have to compile your AHK scripts before into exe-files with the included compiler.

you can use ahk.dll (AHK_H) to call those functions from your python gui on windows

then you'd have to replicate all of your functions for other platforms

gregster wrote:Of course, you can program a GUI in another language to start AHK and other scripts. But how you run a script from a python GUI (what is surely possible) is rather a question for a python forum, isn't it?

Without AHK installed you would have to compile your AHK scripts into exe-files with the included compiler.

So in other words, one would separate all the functions I have in a document into separate files instead. They could even be .exe's if one doesn't have AHK installed. Makes sense. The two concerns are then:

1. In one function, I may have 1-5 other helper functions that simply reduce redundancies and allow me to control consistency. If the functions have to be separated then this means the helper functions will have to either be included in each file OR they must simply be written out in each file. Then if I wish to tweak one helper function in the future, I have to go through every file and edit things manually, which is a mess.

2. Currently with the script always "running," would there be a performance loss if instead files were triggered from another language by either the other language or windows?

guest3456 wrote:you can use ahk.dll (AHK_H) to call those functions from your python gui on windows

then you'd have to replicate all of your functions for other platforms

This seems beyond my level but it makes sense. The entire language is packaged up in a .dll. Is the performance good?

What is the purpose of a cross platform frontend if the backend is not cross platform as well...

joedf wrote:What is the purpose of a cross platform frontend if the backend is not cross platform as well...

What is this magic bean called?

Using AutoHotkey.dll would allow you to load the script into the same process as the Python (or whatever) interpreter, and (presumably) call whatever function at will, so that seems like a good solution.

Otherwise, it is not necessary to compile the scripts. All you need to run a script is a copy of AutoHotkey.exe. If run it from the command line or from another script, there's no need to install it. A compiled script is essentially just a copy of AutoHotkey.exe combined with your script.

Whether or not you compile, you don't need to split the functions out into separate files. You can use command line args to choose which function call. For example, %1%() would call the function named by the first command line arg. (To pass the other args to the function, you would need to pass them indirectly, such as by copying them into non-numeric variables: arg = %2%.)

If you do find a need for separate scripts with shared functions, you can put the shared functions in a separate (third) file and #include it in both scripts. Ahk2Exe merges each #include into the script when it compiles the script (if you compile).

There would be a performance loss if you run AutoHotkey.exe each time you need to "call" a function, as it would need to start a new process and parse the script text each time. You could avoid this by running a persistent script and using some form of inter-process communication, such as ObjRegisterActive (and from the Python side, win32com.client.Dispatch()). However, you'd need to use something else for AppleScript or whatever.


@joedf: What is the purpose of having a frontend and a backend if the two are inseparable? Ulysses already described how two different backends would be used; one on Windows, one on Mac.

@lexikos thanks

lexikos wrote:Using AutoHotkey.dll would allow you to load the script into the same process as the Python (or whatever) interpreter, and (presumably) call whatever function at will, so that seems like a good solution.

Otherwise, it is not necessary to compile the scripts. All you need to run a script is a copy of AutoHotkey.exe. If run it from the command line or from another script, there's no need to install it. A compiled script is essentially just a copy of AutoHotkey.exe combined with your script.

Whether or not you compile, you don't need to split the functions out into separate files. You can use command line args to choose which function call. For example, %1%() would call the function named by the first command line arg. (To pass the other args to the function, you would need to pass them indirectly, such as by copying them into non-numeric variables: arg = %2%.)

If you do find a need for separate scripts with shared functions, you can put the shared functions in a separate (third) file and #include it in both scripts. Ahk2Exe merges each #include into the script when it compiles the script (if you compile).

There would be a performance loss if you run AutoHotkey.exe each time you need to "call" a function, as it would need to start a new process and parse the script text each time. You could avoid this by running a persistent script and using some form of inter-process communication, such as ObjRegisterActive (and from the Python side, win32com.client.Dispatch()). However, you'd need to use something else for AppleScript or whatever.


@joedf: What is the purpose of having a frontend and a backend if the two are inseparable? Ulysses already described how two different backends would be used; one on Windows, one on Mac.

Thanks. So in order of fastest to slowest:
1. using ahk.dll
2. running separately but ahk persistently and using inter-process communication
3. triggering separately with a new process being started each execution

Also, this probably warrants a new thread but is there anything better than AppleScript (which I'm not completely sure applescript can even do) at doing something like using the command WinMenuSelectItem?

your biggest problem is gonna be replicating your AHK functions on Mac/Linux/whatever other platform. so don't worry about your GUI because thats a waste of time at this point. you need to figure out how you will modularize your custom functions to perform the same tasks on other platforms. this is non-trivial and i would be greatly surprised if you accomplished it. the IronAHK project attempted to do this but never picked up any traction and isn't worked on anymore.

AutoHotkey runs under WINE pretty well, you just can't interact with other programs through the mouse and keyboard. For scripts that only do things using behind the scenes APIs, they should work fine. Additionally, GUIs work fine

I mean, I could probably do almost everything through a bunch of keyboard sends but that wouldn't be ideal.

Not sure about WINE. I need the keyboard for some things.

Yeah, that's going to be really hard. I mean, the mac world uses Quickeys which somehow does much of the window/keyboard/mouse manipulation that AHK does but it isn't really a language and it isn't open source / free, which is really restrictive if I want to build software around it.

Even if I do write a bunch of AppleScript code I'll also have to cross the bridge of getting it to work quickly with Python.

Let me know if you all have more input for now. I appreciate you guys being realistic with me here.

for reference:
https://github.com/polyethene/IronAHK