AHK + other language - cross platform
AHK + other language - cross platform
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!
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!
Re: AHK + other language - cross platform
Ahk is windows only. I think you have to try something else... :/
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: AHK + other language - cross platform
There was more to my post than the first line...joedf wrote:Ahk is windows only. I think you have to try something else... :/
Re: AHK + other language - cross platform
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.
Without AHK installed, you would have to compile your AHK scripts before into exe-files with the included compiler.
Re: AHK + other language - cross platform
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
then you'd have to replicate all of your functions for other platforms
Re: AHK + other language - cross platform
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: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.
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?
Re: AHK + other language - cross platform
This seems beyond my level but it makes sense. The entire language is packaged up in a .dll. Is the performance good?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
Re: AHK + other language - cross platform
What is the purpose of a cross platform frontend if the backend is not cross platform as well...
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: AHK + other language - cross platform
What is this magic bean called?joedf wrote:What is the purpose of a cross platform frontend if the backend is not cross platform as well...
Re: AHK + other language - cross platform
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.
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.
Re: AHK + other language - cross platform
@lexikos thanks
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: AHK + other language - cross platform
Thanks. So in order of fastest to slowest: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.
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?
Re: AHK + other language - cross platform
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.
Re: AHK + other language - cross platform
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
Re: AHK + other language - cross platform
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.
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.