ColorBand structs as ID properties

Adds a new ID property type for ColorBands. This feature is needed as part of the new PyNodes development, since node types such as the ColorRamp node have custom storage data in the form of a ColorBand struct, which must be implemented as ID property in order to make the type definition python-based. Other node data such as RGB curves could be added in the same where when required.

The IDP_COLORBAND property maps to the PROP_POINTER rna type, like the IDP_GROUP. A change to the way pointer rna properties are casted in RNA_property_pointer_get (rna_access.c) is necessary: Previously the PointerRNA data pointer could just be casted from the IDProperty pointer directly, since groups were the only id prop type mapping to rna pointer type.

Now the actual pointer to be used for a property depends on the id prop type (IDProperty* for groups, ColorBand* for color bands). The solution is to store the actual data pointer in the idprop->data.pointer. For groups this is the id prop itself (idprop->data.pointer==idprop).

[brechtvl, 2011-06-02 11:13:57]

I think this should be called ColorRamp instead of ColorBand for python. It's a
bit silly to have these different internal and external names for the same
thing, but it's called a ramp in the user interface and python everywhere else,
so probably best to stick to that. 

I would also make the default rangetype 1 instead of 0, my guess is that it's
more common that you don't want alpha.

One thing that is a bit unfortunate is that this makes the generic python module
depend on RNA, can't think of a solution for that though.

http://codereview.appspot.com/4547071/diff/1/source/blender/blenkernel/intern...
File source/blender/blenkernel/intern/idprop.c (right):

http://codereview.appspot.com/4547071/diff/1/source/blender/blenkernel/intern...
source/blender/blenkernel/intern/idprop.c:786: prop->data.pointer = prop;
I think this pointer is not properly set on file read, or am I missing
something?

[ideasman42, 2011-06-03 11:27:51]

On 2011/05/30 16:26:59, lukas.toenne wrote:

So far I like the way ID properties store primitive types and would rather not
have them store colorbands and complex blender structs.

But having custom nodes store color bands is useful, did you consider other ways
of doing this?

[lukas.toenne, 2011-06-05 09:26:09]

On 2011/06/03 11:27:51, ideasman42 wrote:
> On 2011/05/30 16:26:59, lukas.toenne wrote:
> 
> So far I like the way ID properties store primitive types and would rather not
> have them store colorbands and complex blender structs.
> 
> But having custom nodes store color bands is useful, did you consider other
ways
> of doing this?

I totally understand your concerns about complex data as ID properties, i'm not
really convinced of this either. However, i can't really think of a better way
to let python nodes have custom storage data of this kind. Any new system
implemented to allow nodes to do this would basically just implement specialized
id properties under a different name.

A more restricted system could use a generic pointer in nodes (just like current
storage) and store a single struct there based on a hardcoded set of types and
access functions. But this would limit nodes to just one instance of that data
and probably require a different way of setup in python. ID properties provide a
unified interface and reuse of an existing system.