[Bf-committers] Standard way to locate stuff..

Kiernan Holland bf-committers@blender.org
Tue, 13 Jan 2004 10:46:48 -0700

Scalable, Unified way to define configurations for blender.. 

Configurations are files that can contain paths to resources, user
interface preferences, 
subtley put what already goes in a .blend file. 

I just hate everytime I install a new version of blender and go looking for
files that it returns to the 
root directory and I have to jump down through the paths.. It would be
better if there was 
some way to standardize this that would be file system independent and

Define a directory, call it /usr/tmp in both windows and unix.. Then store
directory there called blender_defaults.  In the blender defaults there are
a number of 
directories, one for each userid, in each userid directory there are
preference files 
keyed to the version of blender (user can be allowed to rename these
The directories are set to file permissions of the userid.. In windows the
may not be enforceable. 

The preference files contain the blender environment variable settings that
locate the directories for 
image files, textures, etc.. In Blender's case, the preference files could
be just .blend's . 
But remember joe user may have a need for multiple versions of blender with

At the time a particular version of blender is first used by the user, the
user would be presented with all 
the preference files in their predefined directory in the
"blender_defaults", they could choose one or 
opt to create a new one. Each preference file could be blend file or a text
file.. If the user choose an 
existing preference file, the new one is created anyway but contains a
pointer to the prefered preference 

If this structure is compromised for any reason, blender could always refer
to a relatively located 
".blend" file near the executable, or to the executables internal settings
if that is compromised. But what the blender 
executable would know is "where to look" for its configuration file, it
would not require the user 
to maintain their own organization of configuration files.. It would not
require as it is now for the 
user to have several copies fo the same executable with a different
".blend" file with each..
Ofcourse the loading of any blend file overrides the settings of the
configuration file, this would 
be default behaviour for when blender is executed without a given blend

Again the process is: 
if (blender file is not provided upon execution) { 
	look for configuration file in the organizational structure in "/usr/tmp", 
	look for configuration file in ".blend" local to executable (./.blend). 
	look for configuration settings in executable (no brainer). 

Unified location, easy to define, would allow user to maintain seperate
preferences for each blender or 
to relate several versions of blender to a single preference file. Doesn't
compromise existing configuration 
for blender and previous blenders.

This configuration would only be useful for groups of users, not
particularly useful for people 
who have blender running on their own machine, where having the relatively
located ".blend" would 
suffice.. Reliance on filesystem, /usr/tmp's on unix may not have general
user write access.  
Could prove a disadvantage for previous versions of blender if seen as a
significant feature if  favored by users. 

Other Ideas: 
Could be maintained as a project external to blender, as blender is defined
in a way that just loading a 
blend file configures it.. For instance, there could be introduced to
blender a new parameter that would allow 
blender to contact a local server that offers up configuration files, or
other services useful to blender.. 
For instance, it might offer the name of the local Verse server or a remote
one, it might offer ports on the local 
machine for a multiplayer game.. It would be roughly similar to a name
service as used in corba, but the key is to 
unify a method of finding stuff that is system independent and scalable and
easily configurable/selectable 
by the user.