AutoHotkey Community

Hi, is this compatible with OSX? If not any alternatives you suggest
Thank you!

Laura wrote:Hi, is this compatible with OSX? If not any alternatives you suggest
Thank you!

No, it is not compatible. I am not familiar with alternatives for OSX.

FG

First, you may be able to accomplish all the key mapping you need via the stock system preferences on MacOS. Unlike, Windows, the Mac is very flexible when it comes to managing keyboard shortcuts.

Apple Menu -> System Preferences -> Keyboard -> Shortcuts. You'll see a list of the left side of the preference panel with a number of categories (Spotlight, etc.). The last item, "App Shortcuts", is where you can set your own shortcuts for all applications or specific applications. It's amazing that Microsoft still doesn't offer this in Windows 10.

Another *great* 3rd-party utility for the Mac, is Karabiner (formerly KeyRemap4MacBook). It will do very sophisticated key mapping -- probably on-par with AHK. However, if you want to do something simple, it may have a simple option built-in. For example, I use it to make the space bar behave as a the ctrl key when pressed with another key (saves the emacs pinky).

https://github.com/tekezo/Karabinerapping

Good luck!

[OffTopic]
Why not start to get used to a PC?
OK, you're allowed to use your standard MAC keyboard
[/OffTopic]

AutoHotkey Mappings to emulate OSX behavior with a Mac keyboard on Windows

This AutoHotkey configuration file makes usual keyboard shortcuts work with an Apple keyboard on Windows. It has been testet with a german keyboard layout, but should work under different layouts as well.

[More...]

by Jonathan Ströbele (stroebjo)

Give BetterTouchTool a try. Money may be required, I cannot remember.

Unfortunately AutoHotkey cannot be used in macOS. In terms of ease of use vs complexity and capability, have a look at 2 built-in programs - Automator and AppleScript. After the debacle of Windows 10 I'm trying to wean myself off Windows now in favour of macOS (and Linux Mint Cinnamon) and have just started getting used to Automator first... drag'n'drop automation.

Hope this helps...

I am moving from Mac to Windows, because I have to (job related)

Automator is the natural choice in Mac , but it does not work inside the applications (like AHK can). For mac, there is the open-osource kantu desktop automation - it works quite differently then AHK, but does the same: autoamte mouse and keyboard

Is it possible to run the same AHK code written for Windows on a Mac by using a different software (e.g. Karabiner)?

DevinC wrote: ↑

07 Apr 2019, 10:36

Is it possible to run the same AHK code written for Windows on a Mac by using a different software (e.g. Karabiner)?

I've heard you can do this by translating AHK via another common language, such as Lua. For instance have Lua "interpret" the AHK code by reading regular AHK code and then tranforming it into something Mac OS can understand. (untested on my end, so not 100% sure)

Tigerlily wrote: ↑

07 Apr 2019, 13:08

DevinC wrote: ↑

07 Apr 2019, 10:36

Is it possible to run the same AHK code written for Windows on a Mac by using a different software (e.g. Karabiner)?

I've heard you can do this by translating AHK via another common language, such as Lua. For instance have Lua "interpret" the AHK code by reading regular AHK code and then tranforming it into something Mac OS can understand. (untested on my end, so not 100% sure)

That sounds like a Transpiler or Source-to-Source Compiler, https://en.wikipedia.org/wiki/Source-to-source_compiler. Many other programming languages make use of such. It's interesting that this isn't being done for AutoHotkey. I don't know how well Lua works out as a cross-platform language. C#, Object Pascal, or Red would be good cross-platform candidates as well.

I think the other part of the issue is mindset. The thinking that AutoHotkey code must be married to C++ and Windows, instead of thinking of AutoHotkey as it's own language that could use other interpreters, written in other programming languages.

A quick, read-worthy post from lexikos explaining some of this conundrum:

Can I run AHK on a Mac that is running Windows with Parallels?

Additionally, it appears users in the past have ran Bootcamp and/or Parallels on their Macs to utlilize AutoHotkey - with success. The posts I have seen around the net do not appear to be doing any complex/advanced AHK programming, however, mostly doing simple key remapping as far as I can tell.

Would be awesome if someone could do some testing in this area to see what does/doesn't work. It seems like from lexikos' post that everything should work though. When I have some free time I may do some testing myself and report back

Usually the issues presented about AutoHotkey being on a different OS has been the Windows APIs and Dlls, where the code needs to be different for that OS. However, to make this a bit more complicated, there is WINE (https://en.wikipedia.org/wiki/Wine_(software). Open-source software that provides a Windows runtime enviornment for running applications on Linux and Macs. WINE has been discussed a number of times on the forums, example- https://www.autohotkey.com/boards/viewtopic.php?t=25741 (AHK installer under Linux/WINE).

From that forum post about the installer, what we are getting is that the present AutoHotkey developers are very Windows centric and lack any motivation to create a cross-platform version of AutoHotkey. And because they are so Windows centric, this can result in development choices that makes the AutoHotkey source code even harder to port over to a different OS. Though let's keep in mind that the Windows OS still holds a huge user base. The present AutoHotkey C++ interpreter, installer, etc... would have many "landmines", that I believe a person or a group would have no choice but to create a new fork (think IronAHK in C# as an example) or transpiler.

A person or group would likely have to focus on "translating" the AutoHotkey scripting language (not the C++ source code), and create a new interpreter. Preferably one in a more cross-platform friendly language (in terms of tools available), thus the suggestion of C#, Object Pascal, or Red. C# probably being a bit more easier for those that know C++ to adapt to, where Object Pascal is as almost as close to the hardware as C++, but has more cross-platform friendly tools (Lazarus, FPC, etc...). Object Pascal also has some AutoHotkey-like automation tools, such as Simba (often use for making bots) and WinAutoKey (so far a bit limited), that can provide example code. Red being more of a wildcard with future potential.

Going the way of the transpiler, would be more about translating the AutoHotkey scripting language into a compiled equivalent into another programming language. An interpreter would be running AutoHotkey in a way similar to how it runs on Windows, where a transpiler would be more specific to creating an application that could run on a different OS.

Though interestingly, it's not really known how far or what is the limit that somebody could get with AutoHotkey and WINE. Though I would think to make significant progress, it would likely turn into a fork.

Sounds complicate. AHK is Windows centric so will leave it at that.

DevinC wrote: ↑

09 Aug 2019, 15:31

Sounds complicate. AHK is Windows centric so will leave it at that.

True, but that doesn't have to be the case. I think it requires developers willing to go outside of the Windows OS and possibly knowing a programming language other than C++. Strong candidates would be Lua, C#, Object Pascal, Red, and maybe Dart.

In the case of Lua, I'm a bit surprised there has never been an attempt. I've never really dug into Lua before, as tend to look more at Object Pascal for anything extra, but was surprised by it's possibilities. Lua is also a scripting language, so a source to source compiler (transpiler), seems even more feasible. Lua already has multiple interpreters for different operating systems (like the macOS and Android). So looks to be easier to make an attempt than with C#, Object Pascal, Red, or Dart. With those languages, there would be more of tendency to attempt rewriting the C++ interpreter of AutoHotkey to the different language, which would be a very significant task. This was the case with the now abandoned IronAHK project, which attempted to make a C# interpreter instead of using the C++ one.

Where with Lua, it appears an attempt can be made to transpile the AutoHotkey language to the Lua language directly, not the C++ interpreter. Somewhat of an example of this type of thing is CoffeeScript to JavaScript. In doing so, you could decouple some of the Windows centric thinking because there can be different "translations" of what the Lua code will do, depending on the OS. Tigerlily's suggestion about using Lua, might be worth looking deeper into.

If I remember correctly, IronAHK is supposed to work on platforms outside of Windows if I'm not mistaken.
Either that or I'm making sh*t up.

Delta Pythagorean wrote: ↑

11 Sep 2019, 06:10

If I remember correctly, IronAHK is supposed to work on platforms outside of Windows if I'm not mistaken.
Either that or I'm making sh*t up.

Yes, IronAHK could work on different OSes. This is because of .NET and Mono, and Microsoft's (and the company they bought, Xamarin) push to make C# cross-platform. But part of the problem with IronAHK, and part of why it was never finished, appears to have been a major fight between the developers and the AutoHotkey websites. There is possibly still a lot of bad feelings, so IronAHK went untouched. To include that it requires developers to switch focus from C++ and Windows centric, to C# and cross-platform development, which is harder to do.

Possibly with Lua, things might be a bit easier. Less focus on creating a new C++ interpreter or one in a more cross-platform friendly language (like C#, Object Pascal, Red, Dart), and more focus on "translating"/transpiling scripting language syntax and functions from AutoHotkey to Lua. Lua already has multiple interpreters for different OSes. I'm guessing there are probably way more people that know Lua well enough to attempt an AutoHotkey to Lua transpiler than they are C++ experts at or near developer level or people capable of writing a new interpreter in another programming language for a different OS.

Though it might be a matter of preference, one does have to overcome the eye burn of Lua syntax. It also falls in the bad taste category of Python, where it thinks it's cute not to use any curly brackets for the clarification of code blocks. Particularly for large programs and to help avoid problems with indentation mistakes. Still, seems like Lua might be a good chance for a "cross-platform" version of AutoHotkey.

Personally. I think you as a business need to honestly look at the LARGE amount of potential revenue and business you are passing up by not creating a macOS version of this simple yet useful app. THERE IS NO TRUE ALTERNATIVE LIKE YOUR ANYWHERE FOR MAC!!!

And frankly, I personally believe that if you have not already done so, the only conclusion I come to is you pure 100% lazy-a-holes and I hope you go bankrupt and have horrible diarrhea everyday from now until you finally smarten up and create a macOS comparable version!

But hey, that's just my 2-cents!

AytiH0tKyFn wrote: ↑

30 Oct 2019, 01:29

Personally. I think you as a business need to honestly look at the LARGE amount of potential revenue and business you are passing up by not creating a macOS version of this simple yet useful app. THERE IS NO TRUE ALTERNATIVE LIKE YOUR ANYWHERE FOR MAC!!!

And frankly, I personally believe that if you have not already done so, the only conclusion I come to is you pure 100% lazy-a-holes and I hope you go bankrupt and have horrible diarrhea everyday from now until you finally smarten up and create a macOS comparable version!

But hey, that's just my 2-cents!

I find this funny.

AutoHotkey is free! And developed by volunteers working for free!

Dang, those lazy-a-holes working for free to give away free stuff.

I could see why a macOS user would be confused as macOS and free open source software is not really a thing. Those lazy-a-holes macOS developers that refuse to exist and make something like AutoHotkey.

Only thing worse is an idiot.

FG

Unfortunately there's no way to implement a version of AHK for Mac. Its implementation is way too tied to the Windows API. You would have to emulate so much about the Windows API inside Mac OS that you would end up with an emulation layer similar to Wine. But we already know that such an emulation layer is doomed to fail because Windows is closed-source, and so trying to reverse engineer the entire Windows API is not feasible.
The DllCall function alone can tie any AHK script to the Windows API at such a deep level that the only way to run that script successfully on MAC is with a virtual machine.

AutoHotkey not only is free, it's also open-source. Anybody can take the C++ source code and try to make a Mac compatible version. But for the reasons just explained, you can lose all hope that that will ever happen. AutoHotkey is a Windows tool only.

Getfree wrote: ↑

30 Oct 2019, 18:52

Unfortunately there's no way to implement a version of AHK for Mac. Its implementation is way too tied to the Windows API. You would have to emulate so much about the Windows API inside Mac OS that you would end up with an emulation layer similar to Wine. But we already know that such an emulation layer is doomed to fail because Windows is closed-source, and so trying to reverse engineer the entire Windows API is not feasible.
The DllCall function alone can tie any AHK script to the Windows API at such a deep level that the only way to run that script successfully on MAC is with a virtual machine.

This is not true. People are confusing the C++ interpreter for the Windows OS with the AutoHotkey language. These are separable entities. That means you can create an interpreter for the MacOS, to include in various other programming languages (C#, Object Pascal, Red, Lua, Python, etc...). The C++ AutoHotkey Interpreter is heavily dependent on the Windows API, not the AutoHotkey language.

WINE is about trying to run the C++ interpreter for the Windows OS, untouched or with minimum changes, on the MacOS (for example). This is of course problematic, as you are talking about running an application not written for the MacOS. If you write an interpreter written specifically for the MacOS or use an interpreter already written for the MacOS (as could be the case with Lua), this is a different situation.

Though to be fair to WINE, I haven't seen anybody in recent years on the AutoHotkey community really push hard to see what are the limits of AutoHotkey on WINE. 10 years ago, tinku99 compiled AutoHotkeyX (https://appdb.winehq.org/objectManager.php?sClass=version&iId=17738), that is on GitHub at (https://github.com/tinku99/ahkx/tree/master). Possibly a new modified or fork version of AutoHotkey made to work with WINE for the MacOS might do better than expected.

As for building a new interpreter for the MacOS, syntax such as FileExist(), KeyWait, ExitApp, WinExist(), etc... can be linked to equivalent functions of a different OS. One of the main issues present here, is it requires developers who think differently and want to pursue this. A developer would have to list out all the commands and functions that AutoHotkey does on the Windows OS, and then search for their equivalents on the different OS, which will require a lot of work. Also keep in mind that I'm not saying that AutoHotkey for the MacOS would be a mirror version of AutoHotkey for the Windows OS nor that you would have exactly the same syntax between versions of AutoHotkey, as clearly there are differences between the OSes.

I'm also not saying such a feat (writing a new AutoHotkey interpreter for the MacOS) wouldn't be tremendously difficult and time consuming, just that it is possible. I think the often given excuse that AutoHotkey must be forever only married to the Windows API isn't a valid one.