Overview
In retrospect, it was a less than optimum decision to put everything in the GSAK install folder (or sub folder there in). However, when I first wrote GSAK I was a bit naive and this seemed to be generally accepted. It kept everything in the one place for easy reference and programming.
As GSAK evolved, this folder structure became very much entwined in the internal workings of GSAK. Making any change would break backwards compatibility and there wasn't a huge benefit to be had for the average user.
However, when Vista came along I knew that one day I would finally be forced to make this change. It has taken me a while, but I have finally succumbed!
Basically, the GSAK folder structure needs to be split into two distinct sections:
1. Static file storage
This is where all files will be stored that are "static" and can only be changed by the GSAK Install program. Examples include the main "gsak.exe", help file, shipped image files, etc. On a new installation, these files will default to being installed to [Program files]\gsak. Files here should never be updated, deleted, or moved by the GSAK program.
2. Dynamic (volatile) file storage
This is often know as "application data" and includes any file that can be updated/created/moved/deleted by the GSAK program. Examples include the main settings file "gsak.ini", Locations, Databases, Macros. On new installations, these files will default to being installed to [application data] for the user currently logged in.
Making this distinction and then doing the conversion is where a very large chunk of my time went to implement. When I started the conversion, I identified over 2000 individual lines of code that made reference to the GSAK install folder. Each one of the lines of code needed to be analyzed to see if it should be converted to use [application data] or [GSAK install] - and once converted address any issue that may arise because of the conversion.
Potential macro issues
Unfortunately, making this change means that not all macros will be 100% backwards compatible.
The biggest problem is that many macros have used the $_Install system variable when referencing a particular file or folder in GSAK. The most common example, would be to reference the "macro" folder which is currently a sub folder of the GSAK [install] folder. The "macro" folder will now be a sub folder of [application data]
I have made the decision to convert the $_Install system variable to now reference the [application data] folder. Essentially this means this variable should now be interpreted as the "application data install folder". This should allow for a relatively smooth conversion, as I think at least 90% of macros will then just "work" as is without any conversion.
For those macros that do in fact need to reference the actual GSAK install folder (to use GPSBabel for example), I have added a new system variable called $_ExePath. This system variable will return the full path to the "gsak.exe" file, which will essentially be synonymous with the folder you installed GSAK to within [program files]
So if you have written any macros that use $_Install, you will need to check if you need to change them to use the $_exePath or not.
An example of a popular macro that this will break is the "Widescreen" split screen custom format. This macro uses images that are part of the GSAK install. This is one such macro that will need to change $_Install to $_exePath otherwise the images will not show.
New folder finder tool
It is hard enough to keep track of the location of all the GSAK folders now. The standard Windows [application data] folder adds yet another level of complexity and the full path is rather convoluted.
As this has the potential to make it difficult to explain how to find various folders when offering user support, I have included this new tool.
You can run this tool via "Tools=>GSAK Folder Finder". The tool is actually a stand alone program (like the macro editor and the dual screen). The main reason for this is so you can run the tool outside of GSAK (especially important if GSAK won't start and we need to provide support). Accordingly, this tool has also been added to your main GSAK start up group so that you can start it via your Windows start button.
Operation
Just run the tool and select the required GSAK area from the drop down box.
When you click on the "Show" button. GSAK will open Windows explorer at that folder. This program is "non modal" so you can open more than one folder to view at the same time.
Converting existing installations to run in [Program Files]
The recommended approach for an existing user that has installed GSAK outside of [program files] and now wants GSAK installed here (complete with databases and settings)
1. "File=Backup" and select all files, settings, images.
2. Uninstall GSAK
3. Full install of GSAK 7.6 to [Program files]
4. "File=>Restore" and use the file generated in step 1
Note: Because the existing install folder is saved in the registry, at step 3 the install of 7.6 will still default to your old GSAK install folder. You *must* manually change this to [Program files]\gsak
When you are happy everything is working correctly, you can then use Windows explorer to delete the old GSAK install folder and all sub folders.
Having multiple profiles
One of the side benefits of allowing your "application data" to reside in any folder, is that you can have multiple application data folders or "profiles".This can be very handy for testing. It virtually allows you to have another complete copy of GSAK without having to do another install. These profiles are completely independent, so you can make changes to settings and data and they will not effect each other.To set up another profile, just create a new folder, and then use "Tools=>Options=>General" to change your application data folder to this new location. The first time you do this you will get the following display:
Create new default settings
This option will create fresh set of default settings for GSAK. This is virtually the same as if you did a fresh install of GSAK to a new folder.
Copy your current settings to the application folder
This option will copy all your existing settings to the new application folder
Move your current settings to the application folder
Same as copy, but once the copy is complete, the original files are deleted.
Remove absolute paths for macros (recommended)
The introduction of "relative" macro paths is something that was only recently introduced (version 7.5), so I suspect most users are still using absolute paths.The problem with absolute paths, is that when you copy your settings or do a restore, you macro buttons on your tool bar will still reference the old folder location.By choosing this default option, your macro buttons will be set to just the macro file name and can then "roam" with your current profile even when you do a backup and restore.The only issue then is for users that *do* actually want the absolute paths kept. I feel these will be in the minority, and by making this an option we provide them with a means to preserve absolute paths.
Note: You can force GSAK to start up with a different application data folder by passing the following parameter "adpath: [application data]". For example, if you have settings in a folder called "c:\testing" then use the following to force GSAK to start up with those settings:
gsak.exe "adpath: c:\testing" |
This will also allow you to configure different shortcuts on your desktop for different "profiles".If you do not pass this parameter, GSAK will start up with the application folder that was last used when GSAK last finished.
Existing vs new users
New users that Install GSAK will always default to the new folder structure. As they have never used GSAK before, there will be no prior history to confuse them and it means we then have a default install which is compatible with Vista.
For existing GSAK users, installing version 7.6 (to the same folder as the previous gsak.exe) does not *force* the new folder structure upon them.
The logic here is that the majority of existing GSAK users will just select the defaults on install, which means they will install to the existing gsak.exe folder. They won't *need* the new directory structure. So why force it upon them and increase the risk of support issues related to making such a change.
By leaving the existing structure as is, users will be familiar with the folder structure and it won't "break" any custom procedures they may have internally set up (backups etc). So for existing users, I currently can not see a compelling reason to *force* them to the new directory structure. Version 7.6 should still work fine with the existing folder structure - it is just that the older folder structure will not be available to for new installs (new installs always use the new folder structure).
This also means that for existing users (especially ones that have installed or written macros) macros should always run first up without problems, because $_Install will be exactly the same path as $_exePath.
For existing users that *want* to convert, or are pedantic about *needing* to install GSAK to program files, then please see the "convert existing applications to run in [program files]" topic above.