*The narrowui value was hard coded in all ui scripts, made an user preferences option. Basically this value determines on which area width, it should switch between dual/single column layout.
ToDo: The Changes only take effect when reloading scripts/restarting Blender (after saving as default). Will maybe add the "Reload Scripts" operator next to the button in the future.
* Small fix for Fluid Add Button, when in single column mode. Didn't expand like the other "Add" Buttons.
This adds a new presets menu in the splash screen and the Input section of
User Preferences to choose a preset interaction style, consisting of key configurations
and also other user preferences such as select mouse button, view rotation style, etc.
Currently, just 'Blender' and 'Maya' presets are included, hopefully we can have more
presets contributed (and maintained!) by the community.
It's best to keep these presets minimal to avoid too many key conflicts. In the Maya one
I changed the view manipulation key/mouse combos and also the transform
manipulator keys, not much more than that.
To save an interaction preset, open the user preferences Input section, and press the
[ + ] button next to the presets menu. It will save out a .py file containing any edited key
maps and navigation preferences to the presets/interaction folder in your scripts folder.
---
Part of this commit changes the way that key maps are exported/displayed in
preferences - now partial key configs are allowed. Previously it would export/import the
entire key configuration, regardless of whether individual key maps were edited or not
(which would make them more susceptible to conflicts in unexpected areas).
(note, in blender terminology, a key map is a category of key items, such as
'Object Mode' or 'View 2d'.)
Now, the export and the UI display work in a similar way to how key maps are
processed internally - Locally edited key maps (after pressing the 'Edit' button) are
processed first, falling back to other key maps in the current key config, and then falling
back to the default key config. So it's possible for a key config to only include a few
key maps, and the rest just gets pulled from the default key config. The preferences
UI display works like this too behind the scenes in deciding what to show users,
however using it is just like it was before, the complexity is hidden.
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.
