Upcoming support for portable settings

In my last "all products" update, I discussed how the user interface was being made more useful. In this second, shorter, update I will briefly cover upcoming changes to settings.

As with the previous UI update, this will only apply to new versions of our tool set that have been redeveloped to use the new libraries (at time of writing only an internal build of Gif Animator).

Portable applications?

There's been a couple of occasions where I've received user requests for portable versions of our tools.

All of Cyotek's supported products have been developed using C# and the .NET Framework (either version 3.5 or 4.0 depending on the product). This means they cannot be truly portable in the same way a self-contained C++ application could be. But, as .NET is built into most versions of Windows now, the barriers are mostly related to our software rather than anything else.

Default settings located in the Windows Registry

Currently, all application settings are stored in the Registry located below HKEY_CURRENT_USER\Software\Cyotek. This makes it a little more complicated to sync settings between two machines, or have the binaries on a USB drive for portability.

Changes to settings formats

The new application libraries both change these defaults, and add a bit more flexibility.

By default settings are no longer stored in the Registry, but are stored as XML files located below C:\Users\<UserName>\AppData\Roaming\Cyotek\. You can change this back to the Registry if required, or switch to ini file style settings if that's what you prefer.

This now means it's a lot more easier to sync settings at the very least, although it still means writing to the file system of the host, which defeats the point of sticking the tool on a USB drive!

Settings stored in the users application data folder

The image above shows a screenshot of the new settings folder, complete with several files that contain the application settings, window layouts and toolbar configuration. Although not strictly related to settings, the tools will also cache application data here too.

Ability to override paths

If we truly need to offer portability, then we need to provide a way for the user to specify where settings and data files are located. This can now be done by creating a file named system.ini in the same folder as the application.

Note: The technique described below may change before final release

Currently this file supports the following settings:

UserDataPath - the path where user settings are stored
CommonDataPath - the path where common (all user) settings are stored
TemplatesPath - the path where templates can be found (derived from CommonDataPath)
SamplesPath - the path where samples can be found (derived from CommonDataPath)
SettingsType - the settings format

User should only need to change UserDataPath, and possibly CommonDataPath but the others ought to be fine as is. Each of the four paths accept a value that is relative to the executable folder.

ini

[System]
UserDataPath=.\settings

Using the above example, if the program was on X:\tools, the path where settings would be both read from and written to would be X:\tools\settings.

This makes it possible to reconfigure the software to have their setting files elsewhere (for example a Dropbox sync folder) or located on a USB device and not touch the host system.

Other considerations

At the moment, if you want to overwrite the path, you have to explicitly force this. I'm considering also have the software detect if it is running from a USB drive, and if so, to automatically have settings and data stored on the USB drive relative to the application folder. If you have any comments (on either method), let me know!

I mentioned the SettingsType value above. This can be either ini, xml or registry, allowing you to choose between two text based formats, or the Windows Registry. Of course, choosing the latter throws easy syncing out of the window but the options are there for those who need them.

Another minor change from how Cyotek's applications currently work is that settings are no longer saved as soon as they are changed (well, unless you're using registry settings of course). Instead, they are saved prior to being exported (or new settings imported) and when the application exits.