[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [37260] trunk/blender/source/blender: Support for update callbacks in python defined RNA properties as discussed last meeting .

Brecht Van Lommel brechtvanlommel at pandora.be
Tue Jul 5 11:10:44 CEST 2011


Hi Matt,

There is in fact a self.id_data, and it should work here?
http://www.blender.org/documentation/blender_python_api_2_57_release/bpy.types.bpy_struct.html#bpy.types.bpy_struct.id_data

Brecht.

On Tue, Jul 5, 2011 at 10:13 AM, Matt Ebb <matt at mke3.net> wrote:
> Hi Campbell, I've been looking into this feature a bit further and tried to
> use it in my scripts, and it's not quite as useful as I'd expected.
>
> The main reason for this is the limited access to other blender data - I can
> access self (the property itself), and I can access context, but there's not
> a lot I can do with that. For example if I'm adding an update function to a
> material property, there's not really any easy way of finding the material
> that the property is attached to, via context. I've noticed this for the
> dynamic enums too, just self and context really isn't enough to be useful.
>
> What would be really handy is if there was something similar to RNA usage in
> C, where you have access to not only the pointer itself, but also the data
> that contains that pointer (ptr->data) and also the top level ID block
> (ptr->id.data). This would be much more practical for update functions,
> enabling the sort of things that are commonly done in the C RNA definitions.
>
> One possibility could be to pass those pointers as arguments to the update
> function, but I also wonder if it would it be possible to expose the
> ptr->data and ptr->id.data as children of the python RNA property object
> itself? Perhaps in a similar way to how an RNA property contains flags like
> read only and hidden, its type and subtype, units, etc. Then in an update
> function you could use self.id_data or something like that. I have no idea
> about the practicalities of how this could work in python though, it's just
> an idea.
>
> Regardless, having access to data such as this, however it may be
> implemented, would be very useful!
>
> cheers
>
> Matt
>
>
> On Sat, Jun 25, 2011 at 12:09 PM, Campbell Barton <ideasman42 at gmail.com>wrote:
>
>> @Matt, yes it does use the internal RNA update function, it also
>> disables the readonly state (if set) for the duration of the update
>> call.
>>
>> Agree the animation system should be calling update functions though I
>> think we need to have it optimized for arrays.
>> If you have 20 layers all animated, ideally wouldn't call update 20
>> times for example.
>>
>> Slightly related is the layer animation bug, where setting the layer
>> doesn't always work right because blender ensures at any point in time
>> at least 1 layer is enabled.
>>
>> IMHO it's worth looking into collecting RNA writes per datablock and
>> assigning arrays so the 'set' functions get the new array as a single
>> assignment (currently each index is assigned individually).
>> With this we could run each properties update function once too.
>>
>> - Campbell
>>
>> On Sat, Jun 25, 2011 at 1:20 AM, Daniel Salazar - 3Developer.com
>> <zanqdo at gmail.com> wrote:
>> > Indeed it's weird.. see this example with a driver based on
>> > scene.frame_current. It will not update on frame change but it can be
>> > tricked to do so by adding a variable pointing to an object (even to
>> > itself) with an object level property animated. In this case I
>> > inserted a keyframe on bounding box display type! :p after that it
>> > will correctly update on frame change.. even if the variable isn't
>> > even used in the expression
>> >
>> > http://www.pasteall.org/blend/7167
>> >
>> > what's going on?
>> >
>> > cheers to you two!
>> >
>> > Daniel Salazar
>> > 3Developer.com
>> >
>> >
>> >
>> > On Fri, Jun 24, 2011 at 7:06 PM, Matt Ebb <matt at mke3.net> wrote:
>> >> On Tue, Jun 7, 2011 at 3:50 AM, Campbell Barton <ideasman42 at gmail.com
>> >wrote:
>> >>
>> >>> Revision: 37260
>> >>>
>> >>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=37260
>> >>> Author:   campbellbarton
>> >>> Date:     2011-06-06 17:50:20 +0000 (Mon, 06 Jun 2011)
>> >>> Log Message:
>> >>> -----------
>> >>> Support for update callbacks in python defined RNA properties as
>> discussed
>> >>> last meeting.
>> >>> This means script authors can perform actions using these callbacks
>> rather
>> >>> then on drawing which puts blender in a readonly state.
>> >>
>> >>
>> >> Late reply, I'm just getting some time to look into editing scripts to
>> use
>> >> this and wanted to say thanks for this Campbell, it's great. Just to
>> >> clarify, is this implemented as a proper RNA update function which will
>> act
>> >> exactly like any other C-defined ones? If so, that's great, but useful
>> >> either way.
>> >>
>> >> Probably worthwhile bringing up this issue again too (certain rna
>> properties
>> >> not running update functions in animation system), since it may be
>> affected:
>> >>
>> http://lists.blender.org/pipermail/bf-committers/2010-November/029482.html
>> >>
>> >> cheers,
>> >>
>> >> Matt
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list