[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.
Reasons:
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
predictable.
Description:
Define a directory, call it /usr/tmp in both windows and unix.. Then store
a
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
internally).
The directories are set to file permissions of the userid.. In windows the
permissions
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
seperate
preferences.
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
file.
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
file.
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).
}
Pros:
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.
Cons:
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.
riseofthethorax@earthlink.net
http://www.bl3nder.com/