Also removed some python code to check for node materials within the material and texture properties. It seems to go fine without it, and this should be handled by context instead.
Running scripts directly didnt call the register function, even though this is not essential its good to be able to run a script directly and see changes in the UI.
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
- remove functions such as operator_int(), operator_enum(), operator_string
this mixed with keyword arguments in a way that made them hard to read.
Instead, have operator() always return properties rather then needing an argument.
- rename prop_pointer() --> prop_object(), pointer is more a C thing.
- missed item_enumR(), rename to prop_enum()
- path functions bpy.utils.script_paths(), bpy.utils_preset_paths(subdir)
- further simplified presets, use a generic draw function for preset menus and define the preset subdir and operator in the class
This changes the layout when the properties window gets too narrow to render the contents properly.
Currently implemented for render, scene, world, object and materials, but the rest can be done easily.
Here's a video for demonstration:
http://www.reynish.com/files/blender25/properties_resize.mov
It automatically detects the window width and then skips the indicators that tells the layout to go to the next column. It requires very minimal changes to the UI scripts so we don't have to maintain two versions of the layouts.
Contributors list isnt used much in our C code so probably its easier if people just use svn blame for this.
Can change if this isnt acceptable but I guessed people didnt care so much since most scripts had no header.
