Add Autostart and Per-User Settings

[0xFurtiv]

This change adds scripts to enable per-user Raw Accel settings.

There are three primary parts to this change:

1. A Start Menu shortcut installer script.
2. A Task Scheduler task installer/uninstaller to run the autorun script at sign in.
3. Additional guide instructions to enable this feature.

Since Raw Accel applies globally, users sharing a computer needed to manually manage different settings files if they wanted to have different Raw Accel settings. This change solves that issue by setting the working directory of writer.exe and rawaccel.exe to a user dynamic path with %LOCALAPPDATA%, and automatically applying those user specific settings on sign in.

Result of running install-shortcut.ps1:

Result of running install-autorun.ps1:

This change resolves #113 and is related to #223 #168 #154 #152 #130 #95 #83 #75 #55 #43

---

Notes:

1. Settings are stored under %LOCALAPPDATA%\Raw Accel for each user.
2. If settings don't already exist, we run rawaccel.exe in %LOCALAPPDATA%\Raw Accel to initialize them.
3. Admin privileges are required to add a global task and to write to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs.

[JacobPalecki]

Hey, ack on this PR. This seems like a sensible idea.
The undercurrent of this idea, I think, is turning Raw Accel's user-side code from a group of loose binaries to a properly installed program managed by the OS. I want to think about the implications of that for a little bit before completing this PR outright. I mean, it sounds like a good direction to be going in. But if we do go in that direction, then some of what you're doing in these scripts ought to probably be done in installer.exe instead.
This is a good time to put up a change like you have because I'm working on a new UI for RA. I don't have a roadmap up on github because so far everyone who works on this just chats on discord (which you're free to join, by the way). But since we're revisiting the user-space side of things, let us mull over exactly what we want to do here for a bit and we can come back and figure out what we want RA to do and how.

[0xFurtiv]

The undercurrent of this idea, I think, is turning Raw Accel's user-side code from a group of loose binaries to a properly installed program managed by the OS. ... But if we do go in that direction, then some of what you're doing in these scripts ought to probably be done in installer.exe instead.

I think having all of this managed by an installer would be a neat end goal. You could think of this change as an incremental step in that direction.

But since we're revisiting the user-space side of things, let us mull over exactly what we want to do here for a bit and we can come back and figure out what we want RA to do and how.

Sounds good. Here are some questions I would have:

1. Should we even support per-user settings? (I'd argue YES. Users are already able to personalize their mouse sensitivity natively in Windows. I think we should mirror that behavior when applying Raw Accel settings).
2. If we support per-user settings, where should they be stored? (I'm thinking it should be somewhere under %HOMEPATH% like %LOCALAPPDATA%).
3. How would users from previous versions migrate their settings?
4. Is Task Scheduler the best approach for applying settings when switching between active users?

Until then, feel free to direct those looking for an autostart solution towards this PR.

[eugenesvk]

By the way, why do you need both a link (and why admin?) and a task scheduler?

I've added a PR ScoopInstaller/Extras#16995 to add RawAccel to the Scoop package manager and doing just a registry edit (path/quotes omitted) for local user

New-ItemProperty -Force -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Run -Name RawAccel -PropertyType String -Value \"writer.exe settings.json\"

any downside here besides the fact that it'll be broken if your GUI forces an LOCALAPPDATA path instead of a local settings.json like today?
(think one is that .lnk is more user friendly vs registry?)

[0xFurtiv]

This PR is pretty old and I haven't kept up with changes in this project, so I'm not sure if anything's changed with how the app handles setting storage that would conflict with this PR. Here's what I recall:

@eugenesvk The purpose of this change is to patch functionality onto the app to support different settings for separate Windows accounts.

By the way, why do you need both a link (and why admin?) and a task scheduler?

1. The shortcut sets the location of the settings file to a user account relative path when opening the GUI. This is just a simple way to patch user-specific settings functionality onto the GUI without needing to change the app itself.
2. The Task Scheduler task is for automatically applying user-specific settings on login and when swapping between logged-in accounts.
3. Admin privileges are required to add a global Task Scheduler task (needed so it runs for each user) and to write the GUI shortcut to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs so it appears in the start menu.

any downside here besides the fact that it'll be broken if your GUI forces an LOCALAPPDATA path instead of a local settings.json like today?

I'm not sure, I haven't tested this approach. With the Task Scheduler approach I needed to add an additional trigger to also run on workstation unlock, since the login trigger only runs on the initial login. I don't know if HKCU:\Software\Microsoft\Windows\CurrentVersion\Run has that same issue (not running when swapping between Windows accounts that are already logged in).

[eugenesvk]

and to write the GUI shortcut to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs so it appears in the start menu.

I was thinking why not put it into the user location instead (just like in scoop that creates local .urls), but I guess that just should be a different installation option: install for the current user or install globally for every user (even though the driver will always be installed for everyone)

also run on workstation unlock, since

I see, yeah, if users switch accounts, then the Run registry/shortcut won't launch, so only the task scheduler will work.

So the only thing I'm not a fan of in this setup is the need to use the slow-to-start powershell every single time for such a low level utility startup.
Am I correct that its only benefit is the creation of the settings folder if it doesn't exist (to me this should be left to the actual executable instead of degrading the startup logic) #230

Otherwise I think that for the no-admin package manager local installs I'll leave the current approach and change the path to use local env var whenever this is merged. (and maybe a "global" install should fully follow your logic of having task scheduler with a unlock hook in addition to login)
Thanks!

[0xFurtiv]

Am I correct that its only benefit is the creation of the settings folder if it doesn't exist (to me this should be left to the actual executable instead of degrading the startup logic)

Yep. I think modifying the writer executable to recursively create directories for a settings file path if it doesn't exist would remove the need for the autorun.ps1 PowerShell script.

Like you mentioned before, the driver is installed for everyone, which leads to undesirable side-effect behavior on a computer shared by multiple people. I spoke with one of the lead developers about this awhile back: ideally the whole app is designed to either be a local install without side-effects for other users, or a properly managed administrator global install, rather than a weird in-between of the two. If there's no technical way to apply the driver locally to only one account at a time, then it seems like this project will eventually take the administrator global install approach.