As I worked on it, I realized that the use of a few scripts has the potential to significantly improve the overall user experience, outside of what happens when the user's script is executed.
I haven't implemented all of my ideas yet, but what I have is "complete" enough for general use.
https://github.com/AutoHotkey/AutoHotkeyUX
The new documentation sections are: I also wrote a little about some parts in v2 Beta - installer plans?.
Plans
Well, ideas. I'll add more as I remember them.
Starting with AutoHotkey
AutoHotkey v1.0 was designed so that when a new user ran it, it would create a new script file with some basic hotkeys and instructions, and open it for editing. After the file was created, running AutoHotkey from the Start menu would run the script. Once the script is running, the user can open it for editing via the tray icon. There's a flaw with this process: if the script contains a syntax error, it won't start, and there might be no tray icon to click. Users got into this situation without learning how to locate their "default" script, or perhaps even understanding that the script is a file they can locate and open in an editor manually.
So my idea for v1.1 was to instead direct the user to simple documentation telling them how to get started. (Of course, some users thought the help file popping up was some kind of bug, like there weren't words on the screen explaining what was happening.) I chose not to do anything more complex because I wanted to minimize code size... and C++ isn't that fun.
After thinking about how to replace the AutoHotkey shortcut in the Start menu (given that the there is no single default exe anymore), I realized that there is no need for each AutoHotkey*.exe to have this default behaviour baked in. Instead, "onboarding" can be handled much better with a few scripts that are installed with AutoHotkey or included in the zip. For instance:
- Options can be provided to assist new and returning users to get started, like installing an editor, creating a script, creating a shortcut to the script or setting it up to start automatically when they log in.
- Since we're all about automation, rather than just telling a user how to get started, we can show them, interactively.
Dash -
Currently the v2 installer creates an "AutoHotkey" Start menu shortcut which runs the dash rather than any one AutoHotkey.exe. In its current state, it has hardly more functionality than a Start menu folder of shortcuts (most of the menu items are scripts that can be executed separately), but I imagine it becoming a sort of hub for various convenient functions. For instance:
- Showing active scripts, with the capability to control them. This can extend beyond what the tray icons give access to, can be applied even to older versions, for all scripts and without requiring any modification (or /include).
- Showing recent scripts, allowing them to be launched or edited. Actually, you can get this by pinning the new AutoHotkey shortcut to the taskbar. Recently launched scripts are shown in the shortcut's jump list, regardless of which interpreter was used (as long as they were launched via the shell verbs registered by the installer). Scripts can be pinned to the jump list.
- A user (or tool author) could potentially customize or extend it.
This would provide a point-and-click method of adding scripts to launch automatically when the user logs in. It could either add individual startup entries to the registry or Startup folder, or one (preinstalled) script could run other scripts (and that could integrate the launcher's version-detection logic rather than invoking a launcher process for each script).
If the dash integrates functions for creating new scripts, managing recently executed or running scripts, and setting scripts to start automatically when the user logs in, there is no need for a default script path under the user's Documents folder. Currently there could be many files, depending on which exe the user runs; i.e. AutoHotkey, 'U32, 'U64, 'A32, '32 or '64. For v2, I think we can do away with this and have only the default script in the directory containing the exe (intended as an alternative to compiling). One reason I like this idea is that the default script is currently expected to be found in the Documents folder itself, whereas the Lib folder is found in Documents\AutoHotkey.
...
I'm out of time for now. Some of my other unimplemented ideas were:
- GUI for automatic download and installation of additional versions.
- Prompting user to download and install a #required version.
- GUI for automatic download and installation of editors and other tools.
- GUI for removing specific installed versions.
- Prompt for removing an older version when installing a new one.
- Silent installation and review of command line usage.
Known Issues (updated 2022-06-19)
- If both a HKCU install and a HKLM install are present, the launcher only searches for interpreters under the HKLM installation directory.
- If the zip is manually extracted without first "unblocking" it, Windows may show warnings when running the installed files.
- Uninstall fails to delete some files.
- New script: Empty template throws an error.
- Launch settings: When switching to "Run all scripts with a specific interpreter", the exe defaults to AutoHotkeyUX.exe.
- The "Window Spy" menu option requires AutoHotkey v1 to be installed. This applies not only to the dash, but also to the standard tray menu and main window menu options of any exe that is not accompanied by a copy of WindowSpy.ahk.
- Other fixed issues; see commit history.