Hi, On Fri, Apr 2, 2010 at 12:01 PM, Andrea Weikert <[email protected]> wrote: > How are relative paths handled? I would like a way to better handle > these than they are handled currently - I have some code for a generic > filepath struct that I didn't have time to finish yet but it would be > worth to look at..
Also, resolving a file path with // in it depends on which .blend file the datablock is linked from, I don't think the proposed API takes this into account. > The functions getSystemDir and getUserDir are added to GHOST, which adds > a pretty nasty dependency to BLI_blenlib - have you any idea on how to > solve this? I also don't really see the reason to do this, there is already platform abstraction code in blenlib. If mac needs an objective-c .m file in blenlib I don't see why that wouldn't work. I'm not against GHOST becoming a platform abstraction library but this seems like a strange exception. > There are quite a few functions that need consulidation: BLI_where_am_i, > BLI_where_is_temp, get_install_dir, BLI_gethome_folder, > BLI_gethome_system, BLI_gethome_user and for Windows there's also > BLI_getInstallationDir... > In these functions you can also find the code that needs to go into the > windows version of getSystemDir and getUSerDir. > I think that a bit of planning needs to be done how to consolidate this > with your proposal, otherwise we'll just add more to the mess that is > alsready there. Agreed, probably BLI_bfile_fopen makes most of the calls to these obsolete, but e.g. scanning a directory for python scripts should use consistent functions. > The last issue I have with the environment variables is that if you > create them automatically with BLI_setenv, you will add them to any > computer where you fun Blender for example form a usb thumbdrive even > thought the user there might not want to have anything blender > installed. (Unlikely I know ;) ). > I would prefer to leave a user's system untouched in this case. I don't think setting environment variables like that is permanent? Some more comments: * I don't really see the point of the "environment" file. In order to install blender in a custom location you would already need to set BLENDER_SHARE as an environment variable, why not simple set all of them then? In other cases it could just use defaults hardcoded in the executable. Another thing is that this file is platform dependent, so having the defaults hardcoded means we don't have to set up all the build system to copy the right files. It also means we can run the blender executable by itself, which is a feature I would like to keep. Basically I think this gives you two ways to do the same thing, and it may be more confusing than helpful, actual environment variables work well enough, we don't need to add a configuration file? * It is not clear to me what the point is of having BLENDER_VERSION as an environment variable (or Blender setting any environment variable when it starts up). It would be set only while Blender is running, and for e.g. python scripts it's accessible in other ways already. Just store it as a variable somewhere in the code or use the internal #define? * I can see wrapping file open/close is useful but I don't see the purpose of wrapping read/write if you provide access to the FILE pointer anyway. Otherwise you end up with inconsistent code or wrapping all the functions, like fseek, fprintf, ferror, feof, fputs, .., better to not try this in my opinion. * Do we have a good reason to support both BLI_bfile_fopen and BLI_bfile_open syntax? Might just be historical reasons and we can use fopen syntax everywhere? Brecht. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
