Portable application

[atifaziz]

AeroShot should be a portable application out of the box for 3 reasons:

• Minimal impact and changes to the host system
• Settings can travel with the application, e.g. on a USB stick or even when copying between computers over a local network
• It is what you would expect (self-containment) from a simple and small tool

Currently AeroShot saves and loads settings from the registry. Deleting the executable leaves the system in an unclean state. By saving settings into a text file (INI) adjacent to the executable, the application can be rendered portable.

AeroShot should also be ready to handle the situation that the executable runs from a location (such as Program Files) where the user does not have write permissions. In that event, the settings file should be written to the user's profile.

Having settings in a text file also adds the following benefits:

• Settings can be hand-edited in a text editor
• Settings can easily be transferred between machines
• Settings can be backed up by simply making a copy of the file
• Settings can be reset by simply deleting the file
• Settings can be shared online
• Multiple settings setups can be swapped in and out by simple rename of files; alternatively the file to use can be specified over the command line

I can help with this.

Tasks:

• Loading settings from INI
• Saving settings to INI
• Migration of settings from registry to INI
• Save INI to user profile when permissions don't permit saving next to executable
• Look to load INI from user profile

[toehead2001]

I'm fine with changing it to an .ini file. The original AeroShot used the registry, so it for newer settings was the easiest thing to do.

This is a low priority for me, so if you want to go ahead and write the implementation, go for it.

As you may have already noticed, Caleb (the original developer) compacted several values into the same reg key. e.g. Opaque Background on + Solid Color + Color Value. For your reason of 'can be hand-edited', it would be best to give each value it's own line.

A few thoughts:
I don't care if you use 1/0 or true/false. However, true/false would probably be understood more widely by end-users. Likewise, let's keep the delay timeout in seconds, and then simply change it to milliseconds in code.
e.g.
// Delay
Delay = true
Timeout = 3

[atifaziz]

Yes, I noticed the folding of several value into the same registry entry and I agree that in the text file version, the settings should be clearly separated out.

For Boolean settings, I plan to accept a truthy value, so any of 1, on, true or yes will mean true and anything else will mean false. Hope that's an acceptable solution too and I think it'll just work naturally.

This is a low-priority item for me too. Let's see how it goes.

[toehead2001]

For Boolean settings, I plan to accepting a truthy value, so any of 1, on, true or yes will mean true

That's fine; the user can choose whichever. However, when the program itself is writing to the file, I would prefer it to use true... unless you have a reason to use one of the other values.

[atifaziz]

Any objections with saving settings to file as the only supported mode going forward and loading from registry for backward compatibility only (supports the case where a previous version of AeroShot saved to registry and the new version does not find a settings file but can use the registry as the starting point)?

[toehead2001]

That works.

[atifaziz]

@toehead2001 I agree that when it comes to saving, the program should and will choose one of the accepted truthy. I'm torn between true and yes and I prefer the latter or but I'll grant you true since you've been so kind about merging my PRs. 😄

[atifaziz]

PR #26 adds loading and saving of settings into a section-less INI file that will look like this:

The INI file is a section-less and settings saved will look something like this:

app-version=1.5.0.0
save-device=file
save-file-path=C:\Users\johndoe\My Documents\My Pictures
use-opaque-background=false
opaque-background-type=checkerboard
solid-background-color=White
checkerboard-background-checker-size=8
use-aero-color=false
aero-color=White
use-window-resize-dimensions=false
resize-window-width=640
resize-window-height=480
capture-pointer=false
use-delay-capture=false
delay-capture-seconds=3
disable-clear-type=false

If the file is not found, settings are read from the registry so migration is done on first save.

[atifaziz]

PR #26 is already long and I think the following belong in a separate issue that can be addressed after a merge and possibly in a new release:

• Save INI to user profile when permissions don't permit saving next to executable
• Look to load INI from user profile

The core of the issue is already addressed and complete, which was to have settings in a text/INI file. We just need to review and lockdown on the settings, keys and format.

[toehead2001]

I'm compelled to want to use XML, since .NET make using XML so much easier and simpler. (I didn't know this a few months ago 😕) Sure, XML could be viewed as more complicated to an end user, but if they're the type of user that wants to manually edit a config file, they'll probably be comfortable with XML.

Thoughts?

I know you put a lot of work into PR #26, but XML seems the logical way to go, at least for me. Also, there's a lot of good changes in the PR that are not completely related to ini. I would like to get those changes merged in.

[atifaziz]

XML is good for hierarchical data and documents and so seems a bit of an overkill (too much syntactic ceremony) to use when all you want to store is a list of key-value pairs. That's my logical thinking (using the right tool for the job).

[toehead2001]

Ok, that's fine. I'm not that picky about it. If you could get the merge conflicts resolved in your branch, add the new setting for Window Shadow, and maybe squash similar commits together, I go ahead and get the pull merged.