> I tried to do this once before by adding an index value to the > CurveMap(?) struct so they could be dereferenced into the enclosing > CurveMapping but it was rejected by Campbell.
Yeah, it's far from beautiful code ... but at least this does not require additional index or backpointer to CurveMapping, just the index parameter in the CurveMapping function. Could also be done with a direct CurveMap pointer parameter for clarity (plus internal validity check). This is "only" an RNA extension to expose some C functionality. > This way doesn't really fit into the rest of the rna functions (not to > mention py-dogma) since you're operating on a 'child' through the > 'parent' interface. > > But, alas, this one little thing is the *only* reason you can't create > materials using the py-api so it really needs a good solution. Yes, there are a couple of places where this is a problem (e.g. nodes). Most of the time you get away simply because the parent is the ID data block, which is always passed along with the child pointer itself, but often that is not the case. Here are a few possible solutions that i can think of: 0) Make child data read-only (duh!) 1) Child update actually becomes parent update, with additional parameter to the child in question and validity check. Maybe this can be formalized a bit with specialized update function definitions in RNA for child data. 2) Look up the parent from the library data each time a child updates, i.e. go over all possible parents in the ID data block and search for the child. Only works for library data and could be extremely costly if done often (iirc particle systems do this, see psys_find_object) 3) Store backpointer in children where necessary. Means data and maintenance overhead, especially for small structs (e.g. CurveMapPoint -> CurveMap -> CurveMapping) _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
