UX - Installer and other scripts aimed at improving the user experience

Discuss the future of the AutoHotkey language
lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 05 Jun 2022, 02:49

v2.0-beta.4 includes an installer and some other scripts which I have written with the goal of allowing AutoHotkey v1 and v2 to be used on one system without any unnecessary inconvenience or giving obvious preference to one version. No swapping exes, just double-click a script and have it run with the appropriate interpreter.

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.
Since the shortcut currently runs the dash (see below), it doesn't at any point show the "Welcome" documentation page that tells users how to get started. However, the first option in the dash is "New script", which is a bit more obvious about where the script is being created, and the user is more involved in its creation. Of course, this is only the first beta release including these scripts. The final release should include a more interactive welcome to AutoHotkey.

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.
Startup Manager (doesn't exist)

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.
Fixes available on GitHub:
  • 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.
Last edited by lexikos on 18 Jun 2022, 18:55, edited 4 times in total.
Reason: update known issues

User avatar
joedf
Posts: 8940
Joined: 29 Sep 2013, 17:08
Location: Canada
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by joedf » 05 Jun 2022, 10:58

This is so neat, can't wait to try it all out! :+1: :dance:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]

Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by Helgef » 08 Jun 2022, 02:03

I only read the documentation, but this seems like very nice additions. Thanks for sharing :thumbup: .

Cheers.

iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by iseahound » 09 Jun 2022, 22:07

Instructions for those who are getting errors such as virus detected:

1. Unzip
2. Right Click Install.cmd and Run As Admin
image.png
image.png (17.11 KiB) Viewed 6235 times
3. Install for all users.

Aetzbarr
Posts: 25
Joined: 20 Jun 2020, 06:18

Re: UX - Installer and other scripts aimed at improving the user experience

Post by Aetzbarr » 10 Jun 2022, 00:18

Some questions/bugs:
1. During installation the option "portable" is grayed out, why?
2. Clicking on "window spy" does nothing.
3. When uninstalling the following error message is displayed:
---------------------------
install.ahk
---------------------------
OSError: (5) Access is denied.



Stack:
C:\Program Files\AutoHotkey\UX\install.ahk (277) : [FileDelete] FileDelete(path)

C:\Program Files\AutoHotkey\UX\install.ahk (277) : [Installation.Prototype.Uninstall] FileDelete(path)

C:\Program Files\AutoHotkey\UX\install.ahk (26) : [Install_Main] Installation().Uninstall()

> Auto-execute
Then AutoHotkey is removed from the list of installed apps in Control Panel, but the program is not actually uninstalled - the folder C:\Program Files\AutoHotkey and all subfolders and files still exist.
I do not have v1 installed. System - Win10 Pro 21H2 x64.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 10 Jun 2022, 18:45

As I said,
I haven't implemented all of my ideas yet ...
I'm out of time for now.
I had already been working on it several weeks longer than intended, and may be focusing on other projects for a while. Anyone is free to submit patches via GitHub.

I have updated the first post with known issues.

Portable installations

The "portable" option has requirements for activation. Specifically, someone needs to implement it before it will work...

Window Spy

Window Spy can't be located by the standard logic of any version of AutoHotkey, unless there is a copy of it either in the same directory as the interpreter of the current script, or in the root installation directory. This needs to be fixed by placing a WindowSpy.ahk in the root of the installation. This file must be able to run when launched with the default shell verb (i.e. Run WindowSpy.ahk). I have a solution in mind that will allow all versions to share one Window Spy even when the launcher is disabled.

I also have other ideas for Window Spy, but they won't be implemented for some time.


@Aetzbarr
(Edit: I see now that it is caused by the last minute change to AutoHotkeyUX.exe; it broke the code for self-deletion of the running interpreter.)
That would likely only happen if the uninstaller is not elevated. How did you install, in which mode? Manually elevating the installer, selecting user mode and then reselecting Program Files (which is not the default in user mode) might cause this issue. Control Panel only elevates HKLM installs. Uninstall() does not self-elevate because Control Panel is expected to do it. The code for self-elevation of install.ahk (only used for installation/repair) and install-ahk2exe.ahk only elevates HKLM installs.

@iseahound
If running as administrator bypasses a "virus detection", you need a better antivirus. I suspect "errors such as virus detected" is not an accurate description of a problem that your instructions would solve.


The installer GUI is designed to elevate when needed. Running Install.cmd or ui-setup.ahk as admin will only allow you to get into trouble, such as by installing somewhere for the current user that the current user doesn't have write access to (as described above).
Last edited by lexikos on 11 Jun 2022, 02:01, edited 1 time in total.
Reason: see (Edit)

iseahound
Posts: 1434
Joined: 13 Aug 2016, 21:04
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by iseahound » 11 Jun 2022, 00:44

The antivirus in question is Microsoft Defender or Smartscreen - the one included by default. I removed the $ZONEDATA as well and couldn't install for the current user. Running install.cmd from the zip file instantly triggers a quarantine from MS.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 11 Jun 2022, 03:53

Because of the version number bump, my final testing of the v2.0-beta.4 release revealed a couple of issues that would crop up whenever the path of the UX interpreter changes. The fix I committed was to copy the interpreter to a static path - UX\AutoHotkeyUX.exe. It was getting late in the day and I was (am) getting pretty tired of working on this part of the project, so I pushed out the release without proper testing. The uninstall error is one of at least 3 (4?) bugs caused by this change. Oops. :oops:

Anyway, to complete the uninstallation, you can just dismiss the error message and delete the files manually. Deleting files is the last thing the uninstaller does.

Or you can update UX and then uninstall.

Updating UX

See commits on GitHub for changes.

There's no mechanism in place for updating just the UX scripts yet, but the easiest way if AutoHotkey v2 is already installed is probably:
  • Download the zip from GitHub and extract it to a temporary location.
  • Run ui-setup.ahk.
  • Verify that the correct directory and mode are selected, then click Install.
Currently install.ahk assumes that it is the already-installed copy if it is run without command line parameters, so don't run an external copy of install.ahk directly. Manually copying the UX files into the installation directory is not recommended, as it won't update the file hash list.

User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: UX - Installer and other scripts aimed at improving the user experience

Post by kczx3 » 15 Jun 2022, 08:12

The only thing I've noticed so far is that I'd get the prompt about the executable coming from another computer (internet) each time I ran the Dash. I attempted to go into Program Files and Unblock the executables but for whatever reason I would get an Access is Denied error even after authenticating with administrator credentials. So what I did was uninstalled, then re-downloaded the zip, extracted, unblocked the executables, then installed. Seems to work now without any prompts asking "Are you sure you want to run this?".

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: UX - Installer and other scripts aimed at improving the user experience

Post by TAC109 » 15 Jun 2022, 16:46

It is simpler to just unblock the zip file before extracting, as this ensures that the extracted items will also be unblocked.

Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

UserNameForAH_Board
Posts: 50
Joined: 02 Jan 2018, 15:55

Re: UX - Installer and other scripts aimed at improving the user experience

Post by UserNameForAH_Board » 16 Jun 2022, 19:17

Lexikos: thank you for the installer.

It might help people were the following crucial bit of the instructions to be made more prominent: in order to run the graphical installer, unpack the zip somewhere and then run the unpacked file Install.cmd from the file manager - and that execution is to be as a normal user; do not use the 'run as admin' context menu to run the installer.

EDIT: still, mistakenly I did run the installer as admin but I've seen no bad consequences yet.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 16 Jun 2022, 21:59

Windows built in zip support automatically extracts the files to a temporary directory. It is not necessary to do it manually in that case, let alone crucial.

Running as admin is fine if you are installing for all users.

UserNameForAH_Board
Posts: 50
Joined: 02 Jan 2018, 15:55

Re: UX - Installer and other scripts aimed at improving the user experience

Post by UserNameForAH_Board » 17 Jun 2022, 10:44

I could have been clearer. What I deemed crucial was the provision of pithy and prominent instructions on how one should run the installer. Your comment makes me realise that to that list of epithets - 'pithy', 'prominent' - I should add 'correct'. I would try again, here and now, to provide such instructions - but I worry about creating another emboldened ('prominent') falsehood. Also, I suppose that from this thread people can piece together what to do.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 17 Jun 2022, 22:03

UserNameForAH_Board wrote:... people can piece together what to do.
Directly below the download link in the announcement topic, I wrote
Run Install.cmd to get started.
This is what people should do. Then the obvious: make their choices and click Install. Nothing more.

People don't read detailed instructions. People fail to follow simple instructions (for instance, by doing things that aren't in the instructions). People will of course download from the front page without ever seeing the instructions. If they can't install the program without the aid of "pithy instructions", the code, design or packaging of the installer needs to be fixed.

I had also written
Note that if you use Windows' built-in support for zip files, running this from within the zip should automatically extract the files to a temporary directory.
because I assumed it was common knowledge that when installing software from a zip, you typically need to extract the files first.

Nonetheless, I have updated the release topic to clarify this potential extra step and a workaround for the issue reported by kczx3.
I wrote:Running Install.cmd or ui-setup.ahk as admin will only allow you to get into trouble, such as by installing somewhere for the current user that the current user doesn't have write access to (as described above).
I consider this a minor issue because the user would have to do all of the following:
  • Specifically run as administrator.
  • Specifically switch to "current user" mode.
  • Specifically change the path to one that requires admin rights to delete from.
I considered a number of potential solutions, and so far the simplest and most complete is for the uninstaller to require admin if the installer ran as admin (perhaps via a command-line switch in the registered UninstallString).


If you think there is some other issue that requires additional instruction, you'd better explain it.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 18 Jun 2022, 05:44

kczx3 wrote:
15 Jun 2022, 08:12
The only thing I've noticed so far is that I'd get the prompt about the executable coming from another computer (internet) each time I ran the Dash.
I did some testing on Windows 7 and 11, and determined that this only happens if you manually extract the files before running the installer. When you do that with Explorer, it writes a :Zone.Identifier stream with ZoneId set the same as the zip file. If you simply open the zip file in Explorer and run install.cmd, the files are extracted to a temporary directory without the ZoneId.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 18 Jun 2022, 18:31

I wrote:Manually elevating the installer, selecting user mode and then reselecting Program Files (which is not the default in user mode) might cause [the inability to uninstall due to lack of admin rights].
Actually, it turns out this problem doesn't exist, because install.ahk currently relies only on A_IsAdmin to determine whether to do a HKLM or HKCU install. In other words, running as admin currently installs in HKLM regardless of what you select in the GUI, which means Windows automatically elevates the uninstaller. This was a byproduct of implementing the GUI late in development, and having implemented only the bare minimum of command line switches.

User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: UX - Installer and other scripts aimed at improving the user experience

Post by kczx3 » 20 Jun 2022, 10:12

lexikos wrote:
18 Jun 2022, 05:44
I did some testing on Windows 7 and 11, and determined that this only happens if you manually extract the files before running the installer. When you do that with Explorer, it writes a :Zone.Identifier stream with ZoneId set the same as the zip file. If you simply open the zip file in Explorer and run install.cmd, the files are extracted to a temporary directory without the ZoneId.
I just installed beta.5 in the manner you suggested. Navigated into the .zip from Explorer and ran the Install.cmd. Worked great. I don't think that worked when I first installed beta.4 using the installer but I didn't report that issue. Oops.

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 20 Jun 2022, 17:06

Running Install.cmd from within the zip in Explorer already worked in beta.4, as per my original notes. There haven't been any changes that would account for it failing in beta.4 and working in beta.5. The content of the files only comes into play after they are extracted...

If you run a file called "nope.cmd", Explorer will only extract that file.

TAC109
Posts: 1098
Joined: 02 Oct 2013, 19:41
Location: New Zealand

Re: UX - Installer and other scripts aimed at improving the user experience

Post by TAC109 » 31 Jul 2022, 18:53

@lexikos
In a recent update to Ahk2Exe I added the facility to update Ahk2Exe to the released version on GitHub, plus a similar option for Mpress, UPX and BinMod. As part of this I would like to be able to update UX\installed-files.csv to allow for a clean uninstall.
  • Is it ok if I update this file with the new/amended information?
  • Is it necessary to delete the entry from this file if the corresponding file is deleted?
  • What is the version field used for? Can I set the version field to the version of Ahk2Exe that did the update?
  • Alternatively, is there a UX interface I can use to update this file?
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe

lexikos
Posts: 9556
Joined: 30 Sep 2013, 04:07
Contact:

Re: UX - Installer and other scripts aimed at improving the user experience

Post by lexikos » 31 Jul 2022, 20:35

I think it would be more future-proof to implement a command-line interface for install.ahk to perform updates to the file list. I suppose you would just need add/update and remove for now.

If you update the file manually, note that I used CSV with column names on the first line to allow for some level of changes. If you write to the file, you should preserve whatever columns it contains.

Entries which do not correspond to existing files or that do not match the hash of existing files should not be an issue. A file should be deleted by the uninstaller only if it is listed and the hash matches; otherwise the entry should be ignored.

The version field is mostly redundant, but is there to store version information about files that do not otherwise have version information. Looks like it is only used to identify the UX version at the moment. You would ideally set the version field for Ahk2Exe.exe to the version embedded in that file, but the installer checks the file itself anyway.

Post Reply

Return to “AutoHotkey Development”