That's it. If it can be done with a glue layer on top of existing AutoHotkey code, great. If it requires a total reimplementation inside .NET, so be it.

Major steps

• Implement Hotkey() and Send(), to see 1) whether .NET's thread-pool system makes threading more or less brain-dead easy, or whether it has noticable overhead. 2) Also, just generally whether it "feels" like a lightweight AutoHotkey script or not.
  • there's many important details involved in Hotkey() that aren't trivial to implement, of course, but doing even 10% of it will give us some idea of whether it might work out well
  • the goal isn't merely to get some hotkey example working, it's to try to come up with an implementation that's pretty easy for the user to use, that hides a lot of complexity.
• Find some sort interpretted language to initially target, something that's a good fit. There's no way we can provide examples in all possible CLR languages, and I think that C# is the obvious compiled-to-bytecode one, but perhaps there's a second, somewhat simpler language that we could target for most of our casual-user-oriented examples? (this choice won't be set in stone... just pick something and move on)
• From here on, we're going to have a ritual. Periodically, we'll find a few real-world AHK scripts that we're recently able to re-implement in one/both of our languages. And then we'll compare the final results for complexity. If we're becoming too complex, then we'll stop and refine, refine, refine, until we get things within acceptable margins again. With AutoHotkey as our benchmark, we are Captain Planet.
  • for the first round, we'll use every example from the quick-start tutorial
  • http://www.autohotkey.net/~Titan/
  • http://www.donationcoder.com/Software/Skrommel/
• Begin implementing the bold functions, in something like this order:
  • over time, flesh out more of the Hotkey() intricacies
  • over time, flesh out more of the intricacies of Send() / SendRaw() / SendInput()
  • WinExist() (basically, implement the window.cpp/WindowSearch class)
  • Click()
  • MouseGetPos()
  • WinWait()
  • WinMove()
  • WinClose()
  • #NoTrayIcon (actually, we have to implement the opposite of that first)
  • ...
• Implement non-bold functions:
  • WinMinimizeAll()
  • WinMinimizeAllUndo()

Literature review

• A combination of the .NET interop + API dispatcher could provide an interim solution.
• A number of people are using AutoItX's COM interface from .NET
• Titan is working on a .NET version... a full port of the API to the managed side (said to be complete), as well as a parser/compiler for the AutoHotkey/AutoIt2 syntax (blech... but interesting :).
• questions
  • are there any existing efforts to get something like AutoHotkey or AutoIt working inside .NET?
  • there are a number of people using AutoItX3.dll from .NET
    • are there any major limitations? (answer: look through AutoItX.chm in their download file)
      • how does the threading part of this work? Hotkeys? Timers? OnMessage? OH, I'M SORRY, AUTOIT DOESN'T SUPPORT ANY NOTION OF THREADS.
    • is it possible to somehow produce a single EXE from this? ILMerge is the typical way to statically link .NET modules together, but it only works when EVERY piece is within .NET.
      • write it out at startup?
      • somebody claims to have implemented a memory-only method in C#...
    • if so, is it possible to convince Chris to generate a .DLL version of AutoHotkey so we can remain purely GPL? (for various values of "convince", including "here's a giant-ass patch")
      • If so, one possible way to handle the threading issue is to simply leave out any functionality that involves threads, and implement those purely in .NET. (OnMessage() and timers should be implemented purely in-process anyway...)
      • Another possible way is for AutoHotkey to send messages to the .NET side when they occur.
      • TODO: make a list of all the functions that run "concurrently", ie. that might be interrupted while running, in order to run something else. (all of them?)
        • is it possible to extricate AHK's individual functions from its main loop? (MsgSleep(), for reference)
          • do we want to? You can't have a GUI without a main loop, right?
            • 1) many AutoHotkey programs don't run with a GUI, 2) some .NET languages have their own (potentially significantly better) GUI system
            • 3) even if AutoHotkey was the one that implemented the GUI, we'd most likely want it to run in its own separate thread, and have as many of the other functions as possible run "thread free"
  • even if nobody has tried to implement something close to the API that AutoHotkey/AutoIt provides, has anyone written a portion of the code that would be useful? (and in a compatible license?)
  • if we go ahead with a pure-.NET implementation, then we need to include AutoIt's functions in the survey-of-difficulty.

Design decisions

• Is it possible to make a AutoItX-like interface to AutoHotkey?
• Do we retain the classnameNN device? (what are the pros/cons? would it make it overly complex to maintain both systems?)
• Do we retain the window/control device?
  • this one... I think there's more of a clear reason to keep it... there IS a big difference between top-level windows and non-top-level windows... on the other hand, most low-level operations seem to apply to hWnds, regardless of what they are
• There IS a benefit to largely retaining FULL compatibility with AutoHotkey and/or AutoIt API semantics. It means that users can jump over and start using it right away.
  • At the same time, I think it might be worth having TWO separate APIs... 1) one oriented towards casual users, and 2) an "advanced" one, where people want to be as close to the Win32 API as possible, but with as many of the most-painful stuff smoothed over as possible. If I DID decide to do two separate APIs, I really would want each to be at opposite extremes. And in that case, the AutoIt/AutoHotkey model is a perfect one.
  • Actually, I DO think that most people who want to do hotkeys don't even want a programming language in the first place — they want a super-easy GUI that hides most of the complexity. So, perhaps we should consider THREE layers that the user can decide to work at: 1) GUI, 2) AutoHotkey/AutoIt, 3) win32api with some niceties thrown in.
    • the problem with that is that the GUI takes a ton of work... I haven't seen a good free one produced (and if it were produced, AutoHotkey probably wouldn't be nearly as popular)
• Do we want to retain AutoHotkey's quasi-threading model, or go with full threading? What are the pros/cons?