- fixed this error 7 different functions (deform groups, uv layers & similar).
- support for numbers over 999.
- renamed splitIDname() to BLI_split_name_num(), moved to BLI_path_utils
- don't search CWD/foldername anymore, only CWD/2.54/foldername, since this is the new default build systems use.
- local source paths (./release/scripts) are now treated as system path, otherwise when this is used you cant test ~/.blender/2.54/scripts at the same time.
now addon path is created using the same path functions and selecting where to save the startup.blend
also made some minor changes to path handling funcs.
For !WIN32 systems the fix was in ED_fileselect_set_params
(basically adding the first folder in the sfile->folders_prev list)
For WIN32:
I talked with Nathan (Jesterking) and he agreed that the fix in path_util.c was required too. Without that BLI_path_abs was always making WIN32 paths ending with \ to end with \\
(e.g. C:\Blender\ --> C:\Blender\\)
And this was making the folder to fail ISDIR tests.
replace some long duplicated, ifdef'd if statements for image extension.
- new function: BLI_testextensie_array(), can take an array of extensions.
- define extension arrays: imb_ext_image, imb_ext_movie, imb_ext_sound - we could have more of these.
- removed amiga extensions iff and lbm
Hopefully last fix for path issues for this release
* The config folder should also be searched for in the 'local' path for local installations
(This code was already there, but removed in revision 30440)
* rename BLI_gethome to BLI_getDefaultDocumentFolder to better reflect how this function is used
* replaced BLI_gethome with getenv("HOME") on Linux and Mac where it retrieves location of bookmarks that are inserted as system bookmarks. BLI_gethome was a thin wrapper around these and in this case the user's home directory is what is actually wanted.
* fix for autosave location -> shouldn't use BLI_gethome anymore
* this frees BLI_gethome of having to emulate the local->user->system search path and can now be truly considered as 'home/default location for .blend files'
* removed setting the default G.sce from read_history, was out of context there.
* fix for creating user dir, leftover from previous commit.
jesterKing, please review -> if there are any issues I will fix or revert.
What happens is that blender looks for a directory "python" in the same
place as the executable for local installations, but that also means when
you have /usr/bin/blender it will look for /usr/bin/python, which is an
executable. Now it checks if it is actually a directory and not a file.
separate define for the user and system blender directory name,
on Linux the directories should be named /usr/share/blender and ~/.blender.
Platform maintainers should still check if that's ok.
For user config and data files, first check the 'local' location (where the executable is located), and only then the actual user locations (whatever the convention for the OSes; $HOME, %APPDATA%, etc).
Update after discussions on IRC:
* operating system specific path retrieval is moved back to GHOST, nothing blender specific here though
* cleaned up path functions a bit to remove #ifdefs
* removed Cocoa from blenlib again
TODO:
* Matt, Damien, please check and correct the functions for Cocoa and Carbon, could only put back existing code but needs adjustment
* finish GHOST_getBinaryDir - this should replace the BLI_where_am_i eventually as well as BLI_getInstallationPath on Windows and get_install_dir for the blenderplayer runtime
* It would probably be nice to define GHOST_getTempDir as well and move those out
* more cleanups...
NOTE:
Things are likely broken for macs
Blender crashes when wiring an image input to an image output in the
compositor (not the same image)
The string to keep the full path was usign FILE_MAXDIR, when
has to be both, FILE_MAXDIR + FILE_MAXFILE (240, like FILE_MAX).
broke when including the blend path in the modules filename.
- new function BLI_path_basename(), matches pythons os.path.basename().
replace a number of cases where BLI_split_dirfile was being used to get the filename only.
would only happen when the names of the path and the relative location matched which isnt likely but happened today when Soenke somehow made a file link to its self.
tile cache code in imbuf, but it is not hooked up to the render engine.
Imbuf module: some small refactoring and removing a lot of unused or old code
(about 6.5k lines).
* Added a ImFileType struct with callbacks to make adding an file format type,
or making changes to the API easier.
* Move imbuf init/exit code into IMB_init()/IMB_exit() functions.
* Increased mipmap levels from 10 to 20, you run into this limit already with
a 2k image.
* Removed hamx, amiga, anim5 format support.
* Removed colormap saving, only simple colormap code now for reading tga.
* Removed gen_dynlibtiff.py, editing this is almost as much work as just
editing the code directly.
* Functions removed that were only used for sequencer plugin API:
IMB_anim_nextpic, IMB_clever_double, IMB_antialias, IMB_gamwarp,
IMB_scalefieldImBuf, IMB_scalefastfieldImBuf, IMB_onethird, IMB_halflace,
IMB_dit0, IMB_dit2, IMB_cspace
* Write metadata info into OpenEXR images. Can be viewed with the command
line utility 'exrheader'
For the image tile cache code, see this page:
http://wiki.blender.org/index.php/Dev:2.5/Source/Imaging/ImageTileCache
* removed code that could lead to Blender writing in the Windows directory - is very old cruft and doesn't work on recent versions of Windows anymore and rightly so :)
