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).Good luck!
07 Apr 2019, 10:36Is 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,. 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.
13 Windows Programs That Are Better Alternatives to Mac OS. This app created for Windows can be used in place of the Karabiner app available for Mac users. Karabiner is a one of the best alternatives to Mac OS apps and it is an app which lets you remap one key to another quite easily and Sharp Keys is pretty much like Karabiner so that you. Alternatives to Karabiner. AutoHotkey is a free, open-source scripting language for Windows that allows users to easily create small to complex scripts for. Keyboard Maestro.
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: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 (. 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- (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. 09 Aug 2019, 15:31Sounds 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.
11 Sep 2019, 06:10If 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. 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! 30 Oct 2019, 01:29Personally. 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. 30 Oct 2019, 18:52Unfortunately 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 , that is on GitHub at. 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.
![]()
To achieve this broad range of functions, the app comes with the expansive Customization tools, aimed to both enable users to create simple keyboard shortcut presets, and also fine-tune the exact behavior of their keyboard. Prior to the app version 9.3.0, Karabiner Elements app was known as “KeyRemap4MacBook. All versions of the tool are optimized for use on all Mac products, including Macbook, iMac, Mac mini and Mac Pro. Installation and Use Karabiner Elements is a lightweight application, but it packs a wide array of functions that can change the basic functioning of your MacOS desktop or laptop. Be aware that after installing it you also need to add it to the list of the applications that can take control over your Mac. You can do so by opening your System Preferences and adding it to the list of apps in Security & Privacy tab. After this is done, the app will appear in your status bar with a small icon that describes currently loaded profile. Clicking on profile name will open a drop-down menu with the list of the currently available profiles, shortcut to the Preferences screen, app updater and the shortcut to the EventViewer service that can help you check if the various shortcut settings are actually effective inside your specific applications. Profiles can be switched either via status bar menu or with the custom keyboard shortcuts. In the Preferences window, you can create new Profiles in the MenuBar tab, and set up the exact keymapping rules, key repeat timing, and status messages. It is important to note that search for specific keybindings can be accelerated using the built-in search tool inside the Change Key tab. Novices can edit customization offerings presented by the app, but seasoned users have full freedom to create and manage their own private.xmp file holding all their keyboard customization options. Features and Highlights
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |