This patch is meant to implement Matt's proposal on Resources files paths, as explained on wiki page:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/ResourceFilePaths
It makes the config files reside in the OS standard path (given by the function BLI_getconfig_folder()):
OSX: ~/Library/Application Support/Blender
Linux: ~/.blender
Windows: ...\Application Data\Blender Foundation\Blender
The config files are renamed as stated in the proposal to more readable names:
.B25.blend, .Bfs, .Blog => startup.blend, bookmarks, file-history
The .thumbnails cache that was stored in the home dir is also stored in this standard folder, with the thumbnails name.
Also some small changes for OSX:
BLI_gethome_folder is updated to search in app bundle (Contents/Resources) and in Application Support/Blender.
Small cleanup in blf_lang.c to use the standard BLI_gethome_folder.
It should work on all platforms, but I've been able to test it only on OSX. So review from coders using linux & windows is welcome!
Description
Event Timeline
Thanks, but this method only changes the names.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/EnvironmentVariables
is linked in the bottom of ResourceFilePaths and the idea is to provide other
features, like versioning, and unify the system.
I would prefer if you helped me reviewing the native paths and function calls
required for this, please check source/blender/blenlib/intern/BLI_bfile.c.
Hi, please don't rename the .thumbnails directory. This was chosen on purpose to follow the Thumbnail Managing Standard, so that Gimp and Nautilus (Gnome file browser) can benefit from it too!
With your change, the thumbnail would be stored twice on the user's system.
Thanks,
Andrea
@Andrea: Sure! I was not aware of this shared dir thumbnail standard. I've reverted thumbs.c changes, and updated the patch file.
@gsr: Why not going directly to the final step ? For OSX native paths, they are retrieved by the functions in the util_cocoa.m file I had to create (the required functions being available only for ObjC). A small update can be done to also retrieve the system shared (a.k.a. System Domain) "Application Data" folder.
AFAIK, a retrieval of windows native file paths is already implemented in the BLI_gethome() function in blenlib/intern/util.c
Another point: in the wiki page, you say the paths are separated by ':', but note that it is a valid char for osx filenames, as well as ';'.
Feel free to give me further details by mail on how I can help you to complete this implementation.
util_cocoa.m seems good if I understood it. I will see how to integrate
it (as you can see in BLI_bfile.c, current method used #defines as base).
Thank you.
I saw the MSWindows code, and it seems to be a mix of concepts, that is
why I will need help with that OS too, to have a clear solution and someone
to consult doubts.
And I saw the ":" problem in another bug (something about crash if path
has "/" in filename and not as directory separation), so how do you
propose to work with envvars? ":" is the Unix traditional separator for
envvars that have multiple paths (and I picked MacOSX as Unix for this),
and ";" for MSWindows. Which is the MacOSX one?
Some quick searchs reported MacOSX does not allow ":" or "/" everywhere,
including own Apple programs, no vert strong rules, sometimes work,
sometimes fail. I guess there would be a compromise, as trying to accept
all characters will make .blend portabability hard.
Going back to finish bfile at least for Unix, so we can start testing live,
I will send a mail to the list soon so the info is not just here.
Thanks again for your efforts.
For the functions needed to retrieve OSX native filepaths, I'll suggest that a common prototype is used among different OSes (to replace the #defines), and #ifdef directives help to choose the correct one at build time.
So for OSX, define your prototype & needs, and I'll code the util_cocoa.m (or whatever filename is most adequate) containing these functions.
FYI, the list of path you can query in OSX is there:
http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Miscellaneous/Foundation_DataTypes/Reference/reference.html#//apple_ref/doc/uid/20000018-BAJHBFCH
On OSX reserved chars, the main issue is that the Finder allows the user to name a file/dir with any char, except ':' BUT '/' is saved as ':'. Weird... So the only char not used would be \n but this is not very useful for an envar...
So assuming ':' is not used (raising warning in logs/console if encountered anyway) may be the best option.
Damien
I've updated the patch to take into account recent updates to blenlib.
@GSR: I've also made a patch (BLI_bfile.patch) to replace the static (#define) base paths by calls to BLI_cocoa_getBasePath (of the main patch util_cocoa.m), to keep it working even with exotic/network configs.
As these base paths are OS specific, the retrieval function may be a good candidate to be moved to ghost (in GHOST_System).
Thanks for the patch. Yes, using to calls instead of defines looks a better way
to handle them, and yes, probably they should go somewhere in GHOST.
I will try to give another push to the project in next days.
Commited the start in r26942. Please fill in MacOSX versions for
getSystemDir and getUserDir as you see fit.