UTF Paths in Windows

Add support for utf path in windows by converting utf-16 to Blender's utf-8 and back when it is needed.
Adds support for Drag and Drop, Copy and Paste


Current Issues:
* may be it is me, but mingw won't link
* Needed to be tested if other OSs aren't affected by build files
* Python dislikes not ascii paths
* Probably not all file calls were changed

Quick search over all files
http://www.pasteall.org/27870/c
findintree(base path, search for, doesn't have)

[elubie, 2011-12-29 21:01:09]

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utfconv.h
File intern/utfconv/utfconv.h (right):

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utfconv.h#newcode10
intern/utfconv/utfconv.h:10: 
One general remark, we already have utf8 to wchar_t conversion functions in
BLI_string_utf8.h.

I would like to rather use these than implement the same functionality again.

[elubie, 2012-01-02 18:06:33]

Some initial stuff, review is still ongoing

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c
File intern/utfconv/utf_winfunc.c (right):

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c#new...
intern/utfconv/utf_winfunc.c:12: 
parameters should be lowercase for consistency

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utfconv.c
File intern/utfconv/utfconv.c (right):

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utfconv.c#newcode2
intern/utfconv/utfconv.c:2: #include <stdint.h>
Visual Studio 2008 (which ist still the official compiler used for building
Blender) doesn't have stdint.h.
It is only included in Visual Studio 2010.
This should be fixed before committing, since it doesn't compile.

You might want to take a look at BLO_sys_types.h in blenloader for a possible
approach. Would be nice to maybe pull out these #defines to a different shared
location.

[elubie, 2012-01-03 10:55:01]

Some more comments, hope I'm not too picky, but I think we should start
enforcing more consistend coding overall in Blender.

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c
File intern/utfconv/utf_winfunc.c (right):

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c#new...
intern/utfconv/utf_winfunc.c:1: #ifdef WIN32
The new files are missing the GPL header and contributor info. (Only mentioning
it here, the rest of the files should be fixed as well - utfconv.h/utfconf.c)

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c#new...
intern/utfconv/utf_winfunc.c:50: 
As far as I could see this function is only used once without the parameter
lpSecurutyAtrributes (is set to NULL).
So, to simplify code, this could be removed.

The type BOOL is windows specific, so should not appear in the API - only use
this within the functions if necessary. Reason is that if we need a
corresponding function on other operating systems we don't want to introduce the
new type BOOL.

Also, for consistency, own function names should be lowercase, so what about:

int u_create_directory(const char *pathname) ?

http://codereview.appspot.com/5505080/diff/1/intern/utfconv/utf_winfunc.c#new...
intern/utfconv/utf_winfunc.c:117: /*
remove commented out code

[AlexKu, 2012-01-03 21:13:27]

Updated

[AlexKu, 2012-02-05 18:53:59]

Updated to SVN

[AlexKu, 2012-03-11 17:34:28]

Updated to SVN

[brechtvl, 2012-03-12 12:13:48]

It's compiling on Mac and Linux fine, also seems to be working ok.

http://codereview.appspot.com/5505080/diff/23001/intern/elbeem/intern/utiliti...
File intern/elbeem/intern/utilities.cpp (right):

http://codereview.appspot.com/5505080/diff/23001/intern/elbeem/intern/utiliti...
intern/elbeem/intern/utilities.cpp:195: gzf = BLI_gzopen(filennew.str().c_str(),
"wb9");
This won't compile, the code is not enabled though. This is just for test code
though, not for blender users, would just leave it as a call to gzopen.

http://codereview.appspot.com/5505080/diff/23001/source/blender/blenlib/inter...
File source/blender/blenlib/intern/dynlib.c (right):

http://codereview.appspot.com/5505080/diff/23001/source/blender/blenlib/inter...
source/blender/blenlib/intern/dynlib.c:50: DynamicLibrary *lib;/*change*/
I'm not sure what this comment is doing here?

http://codereview.appspot.com/5505080/diff/23001/source/blender/blenlib/inter...
File source/blender/blenlib/intern/fileops.c (right):

http://codereview.appspot.com/5505080/diff/23001/source/blender/blenlib/inter...
source/blender/blenlib/intern/fileops.c:202: {return ufopen(filename, mode);}
Could you follow the coding style here and in other functions? Put { and } on
own line, not indented.

[AlexKu, 2012-03-12 18:15:51]

Done. Removed from elbeem, added utf LoadLibrary, fixed style

[elubie, 2012-03-16 18:38:45]

Ok, just checked the code again, apart from the license comment is now looking
good to me.
If the license is changed to GPL or BSD like is approved I am ok with this going
into trunk.

http://codereview.appspot.com/5505080/diff/25002/intern/utfconv/utfconv.c
File intern/utfconv/utfconv.c (right):

http://codereview.appspot.com/5505080/diff/25002/intern/utfconv/utfconv.c#new...
intern/utfconv/utfconv.c:25: 
License is BSD like, not the GPL header we usually use when contributing to
Blender. I guess this needs either adjustment or statement from BF that it is
accepted.

[brechtvl, 2012-03-19 11:38:54]

I'd just use GPL here, though if there's a particular reason to use BSD that
could be ok .. further LGTM.