(I posted here because it seems to be the most suitable forum: talking about the future).
Yes, what are the main reasons? Lack of interest? Linux is a decent OS and plays by the FOSS rules. AHK is free and open source. At least the software philosophies converge.
I've heard people say that, “in Linux, no one needs such thing as AutoHotKey”. This is a very short-sighted, to avoid the word 'ridiculous' statement. As we well know, no one needs AHK for anything, it's just godamn convenient (this one is by Lexikos). No one needs Unix's "tr" command (program) either. Or "awk". Or even "grep", the so powerful grep: a Linux desktop user could live perfectly without greping for anything. But those Unix programs are also very convenient for their purposes.
It leads me to think that the Linux community feels like power is all under their fingertips while behind a terminal window. Others could say, “but in Linux everyone is free to examine the source code of the OS and develop programs accordingly.” That's far beyond the point. Windows is an open platform too, you don't need licence or permission from Microsoft to develop an app.
Other think I often hear is “there is no need to develop a Linux version of AHK because there are already plenty of programs which perform similar functions.” False. I know there is a abbreviation expander and a hotkeys utility that could go further than the built-in configurable keyboard shortcuts Linux has to offer in the keyboard control panel, but they can't begin to compare to AHK. AHK is text-based, easy to edit, debug and create, and you don't have to go deep in a cryptic already-pre-built xml or json file. With AHK, the user deals with plain text, a human-readable scripting language; the hotstrings' options in AutoHotKey can easily be chosen with the R, *, c, ? flags. In IronAHK – a past attempt to bring AHK to Linux – on the other hand, we have to select checkboxes! Painful user experience.
And yet another argument: not the FOSS philosophy itself, but the Unix one: “programs should perform only one action, and do it well. The user shall benefit from different applications by using the |pipe| to direct the output.” Again, this would demand typing. And although the Unix philosophy to have atomised programs is nice, it does not exclude the convenience of AHK nor the other way around. Also, AHK is meant for making the life of a desktop user easier, not exactly the one that lives behind the TTY.
Some arguments could be reasonable for being technically based: “we can't simply create a single AHK to handle all desktop environments, all window systems and window managers, because they're all different.” The WinActivate, WinMaximize, FileSelectFolder, GUI functions would be though to import, some say. And that's beyond my knowledge. Is it true?
So, what are the true reasons we don't see people eager to port AHK to Linux or even Mac OS X?
What keeps AHK from going to Linux?
Re: What keeps AHK from going to Linux?
Programs use certain APIs to interact with the system. The API defines what kind of actions one can take within the system.Some arguments could be reasonable for being technically based: “we can't simply create a single AHK to handle all desktop environments, all window systems and window managers, because they're all different.” The WinActivate, WinMaximize, FileSelectFolder, GUI functions would be though to import, some say. And that's beyond my knowledge. Is it true?
AutoHotkey is based on the WinAPI. (Windows API) A lot of commands can be directly found in the documentation of it ( e. g. UrlDownloadToFile ).
Not all actions are porteable. Although there might be some sort of WinMove in Linux it could be completely different from AutoHotkeys.
Yet there are cross-platform languages. They create a language API themselves that acts as a Layer between it's syntax and semantics and the OS. This API then calls the system API for each system.
However such a language often has certain requirements for it's syntax and semantics depending on the background API.
AutoHotkey also uses this technique to make every WinAPI action it implements to make things easier.
It would be tough to keep it simple and give it cross-platform ability, much less to keep it the way it currently is.
Recommends AHK Studio
Re: What keeps AHK from going to Linux?
you want AHK to automate tasks like GUI interaction? Linux itself can't even decide on a standard GUI control format.
the two main linux GUI frameworks are QT and GTK. different linux desktop environments use different frameworks. so now, you expect AHK to interface interchangably with both of those framework APIs? sure anything can be done, but its a lot of work. text editors such as Vim and Emacs have hotkey/hotstring functionality built-in, allowing you quick text manipulation within their editors. sure nothing is a complete replacement for AHK
regardless, the TRUE reasons are pretty simple: time and desire.
you seem to have both, why don't you build it? thats the beauty of FOSS. fork and go. become a contributor to the FOSS community that you are raving about, instead of just an end-user
the two main linux GUI frameworks are QT and GTK. different linux desktop environments use different frameworks. so now, you expect AHK to interface interchangably with both of those framework APIs? sure anything can be done, but its a lot of work. text editors such as Vim and Emacs have hotkey/hotstring functionality built-in, allowing you quick text manipulation within their editors. sure nothing is a complete replacement for AHK
regardless, the TRUE reasons are pretty simple: time and desire.
you seem to have both, why don't you build it? thats the beauty of FOSS. fork and go. become a contributor to the FOSS community that you are raving about, instead of just an end-user
Re: What keeps AHK from going to Linux?
you seem to have both, why don't you build it? thats the beauty of FOSS. fork and go. become a contributor to the FOSS community that you are raving about, instead of just an end-user
OH DEAR, thanks! I'm genuinely flattered. But no, I don't even begin to have the in-depth knowledge to do so. I don't even know the INTERMEDIATE level of AHK itself. I'm prettymuch a user of hotkeys and hotstrings, and some file manipulation functions. I would definitely do if I could. Or I could even pay someone to do if I were a millionaire, I could even constitute a taskforce to do it. The things I know about Linux, on the other hand, are all basic too: I know the existence of the commands, but doesn't mean I can take the most of them. For instance, I don't know what to use "tr" for, even less the awk. All I have is the will. Lack me: time, money, knowledge.
Yet there are cross-platform languages. They create a language API themselves that acts as a Layer between it's syntax and semantics and the OS. This API then calls the system API for each system.
However such a language often has certain requirements for it's syntax and semantics depending on the background API.
I think you want to say it would be necessary to create an additional layer of interaction between the user and the OS kernel, what could potentially increase the response time. Is that correct? In other words, are you saying that an eventual AHK on Linux would have a inherent performance issue?
Re: What keeps AHK from going to Linux?
No, what we are saying that AHK is essentially a wrapper around the Windows APIs.
These APIs do not exist on Linux, so it would not be possible to "port" AHK to Linux, or if you did would require writing linux versions for all the WinAPI functions that AHK wraps.
TL;DR: AHK is inherently windows, and this is not likely to ever change.
These APIs do not exist on Linux, so it would not be possible to "port" AHK to Linux, or if you did would require writing linux versions for all the WinAPI functions that AHK wraps.
TL;DR: AHK is inherently windows, and this is not likely to ever change.
Re: What keeps AHK from going to Linux?
I understand.
Thanks for your inputs though.
Thanks for your inputs though.
Re: What keeps AHK from going to Linux?
There may be some commands that wouldn't translate, but ultimately there's only one thing keeping AHK from going to Linux: lack of someone to do the work.
I don't use Linux. Even on Windows, I only work on AutoHotkey intermittently, and contributions by others are rare. It's already been more than 5 years since I started developing v2...
It would be more work than the average program, due to how much it depends on the Windows API, and how modular the current code base isn't. I have some plans relating to that, but nothing specific to Linux.
I don't use Linux. Even on Windows, I only work on AutoHotkey intermittently, and contributions by others are rare. It's already been more than 5 years since I started developing v2...
Isn't that what porting is all about?... or if you did would require writing linux versions for all the WinAPI functions that AHK wraps.
It would be more work than the average program, due to how much it depends on the Windows API, and how modular the current code base isn't. I have some plans relating to that, but nothing specific to Linux.
Re: What keeps AHK from going to Linux?
As far as I know many thing from AutoHotkey are working well with Wine.
DRAKON-AutoHotkey: Visual programming for AutoHotkey.
Re: What keeps AHK from going to Linux?
Thanks Lexikos. I understand that, when it comes to putting the hands on the bulk, few people actually show up. I would if I could. Still, I love AutoHotKey and thanks for your work. Keep walking on v2!
Re: What keeps AHK from going to Linux?
And I would add this is probably not the most efficient way for a developer to spend his time.
This would require weeks of work and motivated testers.
Autokey already exists https://github.com/autokey/autokey and could certainly be improved. There would also be less work adapting Wine to make it work better with Autohotkey.
Porting Autohotkey to Linux will I think never happen and it is not a bad thing as far as productivity and efficiency are concerned.
This would require weeks of work and motivated testers.
Autokey already exists https://github.com/autokey/autokey and could certainly be improved. There would also be less work adapting Wine to make it work better with Autohotkey.
Porting Autohotkey to Linux will I think never happen and it is not a bad thing as far as productivity and efficiency are concerned.
Re: What keeps AHK from going to Linux?
Here are SOME of the reasons I would very much like to see AutoHotKey on Linux:
Hotkeys
Hotstrings
Contextual hotkeys and hotstrings
If-Else
IfWinActive
IfWinExist
IfWinNotActive
IfWinNotExist
Click, coordinates
Mousemove
Clipboard =
FileAppend
Filecopy
Filemove (and rename)
FileRead
FileReadLine
FormatTime
Loop
Loop, parse
WinActivate
WinClose
WinMaximize
WinMinimize
WinMinimizeAll
WinWait
WinWaitActive
You might find some apps to perform one of two of the above, but that would be a no more than a scratch.
Hotkeys
Hotstrings
Contextual hotkeys and hotstrings
If-Else
IfWinActive
IfWinExist
IfWinNotActive
IfWinNotExist
Click, coordinates
Mousemove
Clipboard =
FileAppend
Filecopy
Filemove (and rename)
FileRead
FileReadLine
FormatTime
Loop
Loop, parse
WinActivate
WinClose
WinMaximize
WinMinimize
WinMinimizeAll
WinWait
WinWaitActive
You might find some apps to perform one of two of the above, but that would be a no more than a scratch.
Re: What keeps AHK from going to Linux?
+1 for AHK on Linux
Early last year (2016) I remember testing functionality of AHK via WINE and the results were dismal. I remember something about needing to keep some sort of AHK GUI open/active for any/most AHK actions to even try to work, and many didn't work successfully. I also believe that window interaction (one of my most prolific uses of AHK) was hindered to only windows that existed within the WINE environment. Which means that Linux windows/environment wasn't really accessible for interaction via AHK. I remember also briefly looking into IronAHK as well but that didn't work out either (last update was 6+ years ago).
I understand it would be a high load of development and testing to progress AHK on Linux further, but count me very interested in that project, if that counts for anything. As of right now, the only reason I don't reformat my work laptop and run Linux instead of Windows is because of how much I rely on my AHK scripts all day to make my job easier, faster, and more efficient. If I could get AHK in Linux the way I use it in Windows, I'd have no use for Windows for work. #deathtoWindows10
Early last year (2016) I remember testing functionality of AHK via WINE and the results were dismal. I remember something about needing to keep some sort of AHK GUI open/active for any/most AHK actions to even try to work, and many didn't work successfully. I also believe that window interaction (one of my most prolific uses of AHK) was hindered to only windows that existed within the WINE environment. Which means that Linux windows/environment wasn't really accessible for interaction via AHK. I remember also briefly looking into IronAHK as well but that didn't work out either (last update was 6+ years ago).
I understand it would be a high load of development and testing to progress AHK on Linux further, but count me very interested in that project, if that counts for anything. As of right now, the only reason I don't reformat my work laptop and run Linux instead of Windows is because of how much I rely on my AHK scripts all day to make my job easier, faster, and more efficient. If I could get AHK in Linux the way I use it in Windows, I'd have no use for Windows for work. #deathtoWindows10
Re: What keeps AHK from going to Linux?
I would disagree on the #deathtoWindows10 part, since Windows 10 is fantastic, but #liveAHKforLinux would be the way to go.
Return to “AutoHotkey Development”
Who is online
Users browsing this forum: No registered users and 38 guests