I know that AHK is only designed for windows so this would probably be an entire change to everything in the "backbone" / "guts" of the language framework but I think it would be really cool if the AHK compiler script could also compile basic android apps, in the same manner you can make basic executable files for windows.

Yes and we also want a Chromebook extension for ahk and a scite4ahk for Chromebooks totally yes this is doable. But really, android prevents you from downloading apps unless its from the app store so itd be annoyingly hard.

Yes, it would be "an entire change to everything". What you want has virtually nothing to do with AutoHotkey; it would be a totally separate project, maybe mimicking AutoHotkey's scripting language if that's what you're after. If you want to build Android apps, AutoHotkey is the wrong tool or platform for the job.

FangLeone, Android does not prevent you from side-loading apps. It is just a setting away.

FangLeone wrote:Yes and we also want a Chromebook extension for ahk and a scite4ahk for Chromebooks totally yes this is doable. But really, android prevents you from downloading apps unless its from the app store so itd be annoyingly hard.

magicinmath wrote:I know that AHK is only designed for windows so this would probably be an entire change to everything in the "backbone" / "guts" of the language framework but I think it would be really cool if the AHK compiler script could also compile basic android apps, in the same manner you can make basic executable files for windows.

I totally agree with you. That hope appears to have temporarily died with IronAHK. Maybe one day it will rise up again. The creator was totally on the right path, just a bit too early and didn't hand over the project to someone.

You might be interested in Limnor, which is an interesting codeless .NET language that produces C# source code and compiled applications. They seem to have (unknowingly to the community here) embraced AutoHotkey somewhat, so have even made instructions for using the AutoHotKey.DLL http://www.limnor.com/support/AutoHotKey_Limnor.pdf

If you make desktop applications in Limnor, you will still need 3rd party tools to port them over to Android. Microsoft does have an application for doing this, called Xamarin. However, you will likely have to get knee deep in C# to port the application. While Limnor is codeless, Visual Studio and Xamarin are not about that kind of lifestyle. The good thing though is Xamarin is for porting .NET apps to iPhones and iOS too, so might be worth it.

This all isn't worth it.
If you want to create Android apps you either have to do it in Java or in Kotlin.
All other attempts will just translate the final code to the android java version.
In that process a lot is lost - mainly capability and performance.
Like you are not able to set specific designs so many cross platform apps look ugly.
Using CSS kinda fixes that but then again also decreases performance.

AHK would have to be rewritten from scratch - different instruction - different paradigm (OOP only) - and different focus (can't focus on hotkeys on android can you)?
So in the end we would get a product that has nothing to do with AHK in the slightest.
What you suggest is not a feature but switching to a new language and developing that language for you.

@SOTE:
It's incredibly different to target multiple desktop and window managers. We just barely manage to target the windows window manager.
Doing that requires access to low level instructions and low level interaction with the OS - specific too the OS.
C# and Java are both made to create code that runs on the system by only scratching the surface and never going deep into the OS.
The only way to circumvent that is using specific libraries written in C that this language would wrap around.
However when you have a langauge that already wraps around this library in a good way - why even use AutoHotkey anymore when you can use the language it is written in?
Regardless languages like Java and C# are a dead end for AutoHotkey and you might as well just develop in C/C++ rather than developing only parts in C/C++ and create multiple releases for multiple OSes.

This all isn't worth it.
If you want to create Android apps you either have to do it in Java or in Kotlin.
All other attempts will just translate the final code to the android java version.
In that process a lot is lost - mainly capability and performance.

Apologies on disagreeing, but from what I've read it appears things are changing or have changed. Definitively not saying there is anything wrong with Java, just that it appears not the only way to go. Companies are using JavaScript (not to be confused with Java) and C# to build applications for use on multiple OSes. For JavaScript there is Electron, Proton Native, Titanium, PhoneGap, Ionic, etc... "Write in JavaScript, run native everywhere". And C#, with Xamarin, has the weight and muscle of Microsoft behind it. Microsoft is making a hard and consistent push of their .NET framework on Android, iOS, Linux, and macOS.

Just finished reading the thesis of a college student who ported his .NET application over to Android last year.

AHK would have to be rewritten from scratch - different instruction - different paradigm (OOP only) - and different focus (can't focus on hotkeys on android can you)?
So in the end we would get a product that has nothing to do with AHK in the slightest.
What you suggest is not a feature but switching to a new language and developing that language for you.

I think that was the point of IronAHK. To port the AutoHotkey language so that it could be used on other platforms. Polythene was on to something. Let's for a second imagine if he completed the project, it would have opened the door of AHK programmers riding the wave of .NET and Microsoft into Android, iOS, Linux, and Macs. IronAHK and AutoHotkey would have been joined in terms of concept and commonality of language and syntax. Finding ways to do things easier or faster through automation, macros, or shortcuts. And Android does have a scripting layer that several other languages have joined the party on like Python, Lua, Perl, JavaScript, etc... https://en.wikipedia.org/wiki/Scripting ... or_Android

@SOTE:
It's incredibly different to target multiple desktop and window managers. We just barely manage to target the windows window manager.
Doing that requires access to low level instructions and low level interaction with the OS - specific too the OS.
C# and Java are both made to create code that runs on the system by only scratching the surface and never going deep into the OS.
The only way to circumvent that is using specific libraries written in C that this language would wrap around.
However when you have a langauge that already wraps around this library in a good way - why even use AutoHotkey anymore when you can use the language it is written in?
Regardless languages like Java and C# are a dead end for AutoHotkey and you might as well just develop in C/C++ rather than developing only parts in C/C++ and create multiple releases for multiple OSes.

The point of IronAHK seems to have been: 1) expand the user base. Users not just on Windows, but on other OSes. "AHK Forever!" OK, maybe I got a little bit carried away, but you get my point. 2) To be able to put the AutoHotkey language and automation abilities to where it's needed. How many of us have Android phones and iPhones? In fact, if Google plays it's cards right, it might be able to eat up Microsoft market share on desktops too. Android tablets, laptops, and desktops are very viable options, which is probably why Microsoft has put MS Office on the Android and is giving away Visual Studio (Community version) and Xamarin to get more .NET developers. 3) Making a more useful tool. If the problem is solved with AutoHotkey, then it's as good as any other language that can be used. AutoHotkey has it's lane where it can be advantageous by it being strong in automation, macros, and shortcuts.

Apologies on disagreeing, but from what I've read it appears things are changing or have changed. Definitively not saying there is anything wrong with Java, just that it appears not the only way to go. Companies are using JavaScript (not to be confused with Java) and C# to build applications for use on multiple OSes. For JavaScript there is Electron, Proton Native, Titanium, PhoneGap, Ionic, etc... "Write in JavaScript, run native everywhere". And C#, with Xamarin, has the weight and muscle of Microsoft behind it. Microsoft is making a hard and consistent push of their .NET framework on Android, iOS, Linux, and macOS.

Yeah I know but in the end it will get translated to Java or in the case of javascript use the built in javascript engine. You do not go against my point.

The point of IronAHK seems to have been: 1) expand the user base. Users not just on Windows, but on other OSes. "AHK Forever!" OK, maybe I got a little bit carried away, but you get my point. 2) To be able to put the AutoHotkey language and automation abilities to where it's needed. How many of us have Android phones and iPhones? In fact, if Google plays it's cards right, it might be able to eat up Microsoft market share on desktops too. Android tablets, laptops, and desktops are very viable options, which is probably why Microsoft has put MS Office on the Android and is giving away Visual Studio (Community version) and Xamarin to get more .NET developers. 3) Making a more useful tool. If the problem is solved with AutoHotkey, then it's as good as any other language that can be used. AutoHotkey has it's lane where it can be advantageous by it being strong in automation, macros, and shortcuts.

I told you why these specific languages are not the way to go for AHK - yet you reply with a response of their general advantages. Once again you do not disarm my point which weighs more than any argument you have made.

As far as I am aware, IronAHK was never targeted at Android. As for automation and hotkeys, I do not believe that Android shares any framework in common with Windows, Linux or OSX. I think the methods of automation it supports are totally different, because both the way the platform is designed and the way it is used are very different than the other OSes. I would be surprised to find that it even supports the concept of a global hotkey or a hook that can be used to create one.

Above all, I have no interest in developing anything for Android or using anything like AutoHotkey on Android.

hello,
if you want program an android without java eg, use Basic4android (b4a). Its very simple, cheap and powerfull with a great community. You can also download a trial version and test. I'm using it since 2011 ans i'm very happy.

The additional point that I would like to add is that other programming and scripting languages have been able to make the jump to being cross-platform solutions. Python, .NET/C#, JavaScript, etc... It's more a matter of being a useful tool with common functionality and familiarity. The list of commands and functions don't necessarily have to be identical for each OS. It appears that IronAHK would have been able to be adapted to do various tasks on different OSes, which at the end of the day, that is all you can ask of a programming tool. It's the concept of having the scripting language being able to take more convenient shortcuts to getting something done, where it would take longer or be more difficult in the traditional programing language.

The fact that we have Android and iOS smartphones, that Linux and the macOS exist, is not going anywhere. Particularly that Android is or is on the brink of being the number 1 OS in market share (https://mashable.com/2017/03/07/android ... Se8iEFWmqJ), and Google can leverage their mobile position and money to gain more market share on desktops. Tablets, Phablets, and mini PCs are hybrid solutions that can blur the lines between desktop and mobile. There could have been/or be an AutoHotkey solution to making tasks easier on other OSes, and which doesn't have to be an exact clone of what is done in Windows. Just saying, maybe there is nothing wrong with thinking outside of the box or keeping an open-mind about it. If not, it seems a bit sad and limiting.

Ahk_fan wrote:hello,
if you want program an android without java eg, use Basic4android (b4a). Its very simple, cheap and powerfull with a great community. You can also download a trial version and test. I'm using it since 2011 ans i'm very happy.

regards
AHK_fan

AHK_fan, looking at B4a and it's related versions, B4i (iOS) and B4j (for desktop applications, is in the area of what I was referring to. However, this method does appear to be using Java (via Java JDK). But even if B4X is using Java behind the scenes, the way AutoHotkey uses C++ or IronAHK was using C#, the point is about the same. Using the alternative language as a way to make things easier, faster, or use shortcuts to get the job done.

Note- Lazarus appears to be an open source alternative to B4X, but they use the Pascal programming language. It too can compile programs for multiple OSes, to include Android.

Debatably, C++ doesn't have to be the language that AutoHotkey commands and syntax are built on top of. That is what IronAHK has at least showed. It could be that the AutoHotkey "language" is on top of .NET or Java. C++ could possibly be used for both Android and iOS, but it seems not as a well supported or as a popular path, though that might not be such a hindrance to some.

It's incredibly different to target multiple desktop and window managers. We just barely manage to target the windows window manager.
Doing that requires access to low level instructions and low level interaction with the OS - specific too the OS.
C# and Java are both made to create code that runs on the system by only scratching the surface and never going deep into the OS.
The only way to circumvent that is using specific libraries written in C that this language would wrap around.
However when you have a langauge that already wraps around this library in a good way - why even use AutoHotkey anymore when you can use the language it is written in?
Regardless languages like Java and C# are a dead end for AutoHotkey and you might as well just develop in C/C++ rather than developing only parts in C/C++ and create multiple releases for multiple OSes.

Was not trying to get into it with you, but simply responding to AHK_fan's post about B4X, as was reading up on it.

In regards to C++/C VS Java, C#, etc... This can depend on what a person views AutoHotkey to be and the goals of a particular scripting language. That people see this differently is understandable. A person or group might be specifically interested in Android or .NET, and want to focus in that direction, versus a cross platform solution for many OSes. I'm not saying it's wrong if a person wanted AutoHotkey for the macOS, just being open about the possibility of it.

A user might be seeking a way to automate applications on his Android, such as have a particular app start at a certain time and send an e-mail or give an alert if a certain e-mail arrives. The level of scripting they want or require doesn't have to go that deep into the OS. Duplicating the full spectrum of AutoHotkey on Windows might not be what is wanted, so how they go about doing what is desired could be very different. It could be a matter of borrowing AutoHotkey syntax and commands to describe and do things that existing scripting languages on the platform does not or isn't focused on. Maybe there is a way to do the same thing with Python, JavaScript, etc... But maybe that person rather use AutoHotkey or the language syntax instead.

That a ported version of AutoHotkey understand various scripts, or uses some of the syntax or commands used by the Windows version, doesn't mean it has to be 100% compatible or use C++/C. I mentioned this, because that is what I interpret that Polyethene was showing with IronAHK and C#, in reading the old forum posts (https://autohotkey.com/board/topic/3148 ... mac/page-3). Things like "A cross platform abstract class with support for X (written by Tobias92) will be included after the syntax engine is complete." (https://autohotkey.com/board/topic/3148 ... mac/page-4). However, in his case, he was seeking as much compatibility as possible with the official AutoHotkey version, where I'm saying that doesn't have to be the goal or point of different developers. What Polyethene did with C#, could be what someone does with Java. I'm not trying to rain on anyone's parade. Even if it "must be done" with C++/C and doesn't have all the options of the Windows version, it could still be usable to various people.

If a person feels that AutoHotkey can only be C++/C and on Windows, not trying to change their mind. Just stating that others can believe differently or see AutoHotkey more in terms of the language and syntax used as opposed to the programming language the source code was made in. I'm sure there are many other AutoHotkey users like magicinmath, that hope AutoHotkey was on other OSes. How to do get it on other OSes or no desire to see it on anything but Windows, could be a matter of opinion or preference. Both views are fine by me.

So you didn't understand what I wrote.
Java has no built in API to create Hotkeys for the entire system.
We would have to get an API that would provide it or built our own - in C/C++ or some other language that Java can use that can also implement super global hotkeys.
So in the end we would write our Hotkey code and most of the language features in C/C++ for Java to use in. Also we have to write a C library for every different OS.
So in the end we would rewrite AutoHotkeys core in Java and built the entire featureset into a dll/whatever linux uses for libraries which will will be shipped with the distribution !specific! for your OS.
the only thing that would change in comparison from now is the rebuilding of the AutoHotkey core in Java - which is more work than making AHKs current core modular and targeting different OSes.
So switching the language doesn't bring any benefits at all.

nnnik wrote:So you didn't understand what I wrote.
Java has no built in API to create Hotkeys for the entire system.
We would have to get an API that would provide it or built our own - in C/C++ or some other language that Java can use that can also implement super global hotkeys.
So in the end we would write our Hotkey code and most of the language features in C/C++ for Java to use in. Also we have to write a C library for every different OS.
So in the end we would rewrite AutoHotkeys core in Java and built the entire featureset into a dll/whatever linux uses for libraries which will will be shipped with the distribution !specific! for your OS.
the only thing that would change in comparison from now is the rebuilding of the AutoHotkey core in Java - which is more work than making AHKs current core modular and targeting different OSes.
So switching the language doesn't bring any benefits at all.

No way was I arguing against your high level of programming knowledge, but debating the point about being open-minded about cross platform solutions and development. Other languages had people making the jump. PyAutoGUI (in Python) for example, https://pyautogui.readthedocs.io/en/lat ... ction.html.

If someone were to come along and want to develop for Android, .NET, macOS, etc... Maybe they should be embraced and supported, even if the end result will be somewhat different to AutoHotkey for Windows.

I dont see pyautogui working on android.
Also if you check the github repository you will see that this project for automation in the python language has more people working on it than the entire Autohotkey language.
It's just the automation part thats being handled there and not even an entire language.