[Bf-committers] Accessing Files (new config locations, fopen wrapper, etc)

[Brecht Van Lommel]

Hi,

On Fri, Apr 2, 2010 at 12:01 PM, Andrea Weikert <andrea at aweikert.de> 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.