Talked with Brecht and Campbell and they both agreed that bpy.types should match bpy.props
In the ideal world we would rename bpy.props to BooleanProperty. This would break scripts though. So we go for a compromise and at least have some consistency.
- rename define DISABLE_SDL --> WITH_SDL (which was already used in some places)
- blenders interation preset was using orbit rather then turntable 3d view preference (different from factory defaults).
- tagged some unused rna args.
This branch adds mostly organizational improvements to the node system by renaming the node folders and files. A couple of internal features have been added too.
Detailed information can be found on the wiki page:
http://wiki.blender.org/index.php/User:Phonybone/Particles2010
An example of how this is useful - an importer mixin could define the filepath properties and a generic invoke function which can run the subclasses exec for each selected file.
- Panels and Menus now skip the property check when registering.
- renamed _idproperties_ to _idprops_ in function names, function names were getting very long.
split PropertyRNA off into 3 types, base type, collection and array, since array and collections needed internal checks inside almost every function its better to have the, as subclassed to the property type. This makes introspection more useful.
Also made printing of structs and properties prettier giveing type and length.
Fixed and completed support for returning multiple values. This includes support for returning arrays, both fixed and dynamically sized. The way this is achieved is by storing an additional int value next to the dynamic parameter in the ParameterList stack which gets passed to the C function as an additional parameter. In the case of return parameters it is duty of the C function to set this int to the correct length value for the dynamic parameter (which makes sense). Note that for the dynamic output/return parameter it is assumed the function has allocated that memory (which gets freed automatically).
Also, I cleaned the makesrna's bridge function generation code a bit and renamed PROP_RETURN to PROP_OUTPUT, which represents better the reality now that there are multiple returns. The function now to mark multiple returns (outputs) is RNA_def_function_output.
For an example, look at Action.get_frame_range in rna_action_api.c, by the way Aligorith I removed the #ifdef for this function now that there's support for returning arrays, feel free to modify (the function seems to work).
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/
This means you can have a pose bone for eg and get the path...
pose.bones["Bone"]
uses rna internal functions, so will work for sequence strips etc.
- StructRNA.get(), used for getting ID props without exceptions...
val = C.object["someKey"]
or..
val = C.object.get("someKey", "defaultValue") # wont raise an error
- change rna property for testing if rna props are editable, test the flag rather then calling the function since the function depends on blenders state.
- fix a python exception with the ID-Property popup UI (when editing in more then 1 step)
eg.
scene.objects.link()
object.constraints.new()
mesh.verts.transform(...)
mesh.faces.active
PropertyRNA stores an StructRNA pointer where these can be defined.
* Enums with an _itemf callback now never get context NULL passed in,
rather a fixed list of enum items are defined which should contain
all items (if possible), from which the _itemf callback can then use
a subset.
