Paths and Windows Installer Fixes

This patch attempts to address windows installer and script/configuration file path issues. In particular:

* Addon scripts install not installing to the user path, but rather installing them between system scripts.
* Windows installer not working for non-administrator users or multiple users.

They are related, and need to be fixed simultaneously to avoid breakage. The fundamental issue is that system files and configuration files are mixed up. The windows installer is writing system files to the configuration directory, and user defined scripts and configuration files can be written to system directories.

The available paths are ambiguous, so I've removed some and for others, mostly the change has been to get user paths before local paths. For the windows installer, scripts and other datafiles are now always installed next to the executable, there is no longer an option for their install location.

One issue is that of compatibility with existing files installed in AppData (i.e. system files written to a configuration directory). For a new 2.58 version the scripts directory now do not get copied over from 2.57 to avoid the problem, and until the version bump to 2.58, addons will still be installed to the local path as they were before.

The patch is now quite well tested on Mac and Windows, and should work on Linux too. Feedback welcome.

[brechtvl, 2011-05-24 11:05:54]

Windows installer compatibility

[brechtvl, 2011-05-24 11:08:48]

Latest change should fix issue with existing system script installation in user
configuration directory:

* Copy previous settings operator will not copy over system scripts to 2.58.
* 2.57 builds will use local path as user scripts directory in case user path
contains 2.57 system scripts from installer, until version is bumped to 2.58.

[brechtvl, 2011-05-24 13:46:09]

Uninstaller changes and compatibility fix

[brechtvl, 2011-05-24 13:52:41]

Latest patch is quite well tested now on Mac and Windows, for non-admin/admin
installs, running from .zip with 2.57 installed, migration of old files to 2.58,
uninstall, etc.

One remaining issue is that when removing configuration files from the
installer, it will remove the files from the admin account when running from a
non-admin. I couldn't figure out how to get the $APPDATA for the user that
launched the uninstaller.

[jesterKing, 2011-05-24 18:37:12]

Otherwise a solid patch, except that this makes portable installs completely
impossible. I'd prefer to see Blender still check for config/ (startup.blend,
bookmarks.txt, recent-files.txt) instead of now defaulting to home dir only.
Especially on portable installs you never want Blender to write to the home dir
(%APPDATA%).

If that gets fixed, the other changes are good.

For the installer there is no need to support the portable install though - so
no need to offer installation of config et al into install dir.

[jesterKing, 2011-05-24 18:48:46]

On 2011/05/24 18:37:12, jesterKing wrote:
> Otherwise a solid patch, except that this makes portable installs completely
> impossible. I'd prefer to see Blender still check for config/ (startup.blend,
> bookmarks.txt, recent-files.txt) instead of now defaulting to home dir only.
> Especially on portable installs you never want Blender to write to the home
dir
> (%APPDATA%).
> 
> If that gets fixed, the other changes are good.
> 
> For the installer there is no need to support the portable install though - so
> no need to offer installation of config et al into install dir.

Hrm, looks like it already is broken >:(

[jesterKing, 2011-05-24 19:16:43]

Excuses for the earlier foobarring with portable install config/ testing - was a
mistake on my side (it works in trunk).

I have now annotated the parts that break the portable install ability. These
should be fixed, then IMO good to go.

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
File source/blender/blenlib/intern/path_util.c (left):

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
source/blender/blenlib/intern/path_util.c:1029: if (get_path_local(path,
"datafiles", subfolder, ver)) break;
shouldn't be removed (portable installs)

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
source/blender/blenlib/intern/path_util.c:1039: if (get_path_local(path,
"autosave", subfolder, ver)) break;
shouldn't be removed (portable installs)

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
source/blender/blenlib/intern/path_util.c:1050: if (get_path_local(path,
"config", subfolder, ver)) break;
Shouldn't be removed (portable installs)

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
File source/blender/blenlib/intern/path_util.c (right):

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
source/blender/blenlib/intern/path_util.c:1043: if (get_path_user(path,
"datafiles", subfolder, "BLENDER_USER_DATAFILES", ver))	break;
This change and the next few changes regarding get_path_local shouldn't be made.
It's important we always check get_path_local first, otherwise our ability to do
portable installs will be broken.

http://codereview.appspot.com/4529081/diff/8003/source/blender/blenlib/intern...
source/blender/blenlib/intern/path_util.c:1077: if (get_path_user(path,
"scripts", subfolder, "BLENDER_USER_SCRIPTS", ver)) break;
Still check get_path_local first, for portable installs.

[brechtvl, 2011-05-24 19:30:39]

Portable install fix

[brechtvl, 2011-05-24 19:32:14]

I wasn't aware portable install was a feature, but it's not hard to add back.
But it needs to be implemented different, simply getting the local path before
user path breaks non-portable install. It's also not handled this in
BLI_get_user_folder_notest and BLI_get_folder_version, so e.g. python scripts
saving configuration files will not save in the right location.

Attached a possible solution, where get_path_user returns get_path_local if a
portable install is detected (by checking for the existence of a local config
folder).

[jesterKing, 2011-05-24 20:22:54]

On 2011/05/24 19:32:14, brechtvl wrote:
> I wasn't aware portable install was a feature, but it's not hard to add back.
> But it needs to be implemented different, simply getting the local path before
> user path breaks non-portable install. It's also not handled this in
> BLI_get_user_folder_notest and BLI_get_folder_version, so e.g. python scripts
> saving configuration files will not save in the right location.
> 
> Attached a possible solution, where get_path_user returns get_path_local if a
> portable install is detected (by checking for the existence of a local config
> folder).

This patch with the latest additions works great, including the installer.

LGTM.

[brechtvl, 2011-05-27 09:58:13]

Committed.