[Bf-committers] Native path handling for blender

Yomgui yomgui1 at gmail.com
Wed Feb 22 14:41:09 CET 2006


Hello Ton,

If you remember, I had sent you on Blender-dev ML a proposal idea
about rewrite Blender to handle paths correctly on various platform.

Currently Blender handles 2 types of paths: POSIX and Win32.
But it does that in a very ugly way: each function that needs to
manipulate paths has its own code... that repeat some unneeded part of
code and increase the amount of work for platforms maintainers at each
modifications.

In second hand, I've ported successfully Blender 2.39a on MorphOS (PPC
platform, ** NOT ** POSIX). But in my first shot I've recoded too much
functions as others platforms have done.
It was an error.

Now I've a better solution and I've seen in the 2.41 releases that
you've already started something identical.

These is the idea and the deal:

The best solution to virtually support all platforms is recode Blender
to use native path directly.
How to do that without changing too much things?
Simple... I'm currently recoding blenlib to have a couple of functions
to handling path in native way. So, blenlib will bring an abstraction
layer for paths. After that, all others internal layers in blender
must use this layer.

But you 'll say "if someone save his .blend file on platform X and
re-open it on platform Y, saved path 'll not be supported!".
To resolve this problem the Library module where .blend files are
saved/loaded, will be recoded to save path in POSIX model.

Why POSIX? It's not the perfect one, but all path symbols are
bijective: a '..' always stands for a parent, a '/' always stands for
a directories separator, etc...
On some platforms (like MorphOS) a '/' can be seen as "parent dir" or
dir separator, that increase the complexity of our code.

So I think that POSIX path may be translated easily into any others
platform path model.

And now, why to to use POSIX model everywhere in Blender? because
there are many OS functions that need only native paths, like fopen()
or even Python API!

In some couples of days I will be able to send you a diff (based on
2.41) for your approval.

Another good thing that comes with this solution: users that don't
know POSIX should be more happy to handle, copy&paste, etc, paths in
native ;-)

Thanks,
Guillaume


More information about the Bf-committers mailing list