Hi, Great to see a strong consensus! Small details can be worked out over time, but I think this is enough to get moving forward with.
Some replies to some of the details mentioned: On 11/05/2010, at 19:37 , Brecht Van Lommel wrote: > Proposal looks fine to me, but I agree with this. We can avoid a > wrapper script, making it use the folder in the same directory doesn't > conflict, so it could just look for a "datafiles" in the same folder > first. Yep, that can work. The reason I liked the environment variables was that it's explicit and clear, trying to avoid the current situation where it's hard to know exactly where the files are being sourced from. But if this is done clearly, behind the API (so people don't just assume to find things in the exe dir) it should be fine, yeah. > Saving temp to user locations is discouraged, it can cause serious > slow downs when the directory is network based. Some are suggesting > using same place than base blend for quit and temp blend, which would > make sense, if auto cleaning is not desired and what is more > important, it would avoid collisions in cases like editing > foo/items.blend and bar/items.blend (even having PID, you still have > to guess which items.blend it refers to). This doesn't really affect the API etc so I'm not too worried about it at this stage, more of a matter of implementation for each OS. As for slowdowns on network locations, I'd imagine that would be a matter of redirecting the path in those situations with environment variables (as this would be the exception rather than the rule for most users). As for saving temp files alongside project .blend files, I guess this is made a bit more complicated by the fact that you can have 'useful temp files' such as .blend backups, vs 'temporary temp files' that are more like caches that can be recreated and aren't very important. Personally I wouldn't like lots of autosave files alongside my scene files (a subdir may be more acceptable), and I think if the main reason for doing so is to make relative paths work etc, then it would be better to fix that actual problem at its source (eg. something like storing the original file path in the temp .blend file - i thought this was implemented actually). Anyway again, this doesn't really affect the api much, in the future it could conceivably be implemented as an option that overrides the BLENDER_TEMP with the current .blend file path, so that code using the api works the same. So I'm happy to go ahead get something working with the current design here. On 12/05/2010, at 09:54 , GSR wrote: > And a third thing, BLENDER_USER_CONFIG should have a > BLENDER_SYSTEM_CONFIG counterpart to store the system wide defaults. Hm, this complicates things a bit more, but perhaps is doable. At first I thought, no Blender should function properly without needing configuration files (the defaults are part of the blender executable itself and preferences are only created as needed). But I realise that this is probably useful for bigger installations (eg. at a school having a set of default 'my school preferences' saved for users of that specific environment). In this case, SYSTEM_CONFIG should be read-only and not defined by default, taking a lower precedence to USER_CONFIG - and making sure that all newly saved preferences end up in USER_CONFIG. Initially (until this uses environment variables), this can just be hardcoded to an empty path. I've added a note about this to the proposal wiki page. cheers, Matt _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
