[Bf-committers] Python API change breaks Rigify

Nathan Vegdahl cessen at cessen.com
Sun Feb 17 16:18:20 CET 2013


I believe there are some other use-cases that this restriction
hinders/prevents without additional features in the API.

IIRC, last time this came up, Matt Ebb spoke up regarding his
RenderMan exporter, where selecting a shader file adds its parameters
as properties to the material, or something like that.  I'm not sure
what the best solution for such use-cases would be.  Of course a
"process shader" button could be added, similar to the "add rigify
layers" button.  But that's not ideal for a clean, transparent user
experience.  Maybe some kind of UI hooks...?

> Also, manipulating data can cause a redraw, which enters a feedback
> loop using 100% CPU while idle.

Well, you can't prevent Python code from doing things that are
arbitrarily expensive.  IMO that's better to enforce via code review.

But still, I agree, this is a good restriction to have in retrospect.
Although from my perspective it's more about forcing the API to grow
to accommodate doing these things properly.  Now I get to poke you
when I can't accomplish something due to this restriction!  Bwa ha ha
ha ha. ;-)

> At the moment Rigify just has a button to add layers if they are not
> created, ideally blender could support collections that default to a
> non-empty list, but this isn't such a common thing to be doing.

Can we put this on a todo list somewhere, so that it doesn't get
forgotten?  It may not be common, but it is useful.  I would like it
for Rigify.

--Nathan


On Sat, Feb 16, 2013 at 8:32 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Fri, Feb 15, 2013 at 12:59 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> I'm having difficulty tracking down the revision that caused this, but
>> this error is now coming up in Rigify:
>>
>> ----
>> Traceback (most recent call last):
>>   File "/home/cessen/Projects/blender/build/bin/2.65/scripts/addons/rigify/ui.py",
>> line 173, in draw
>>     bone.rigify_parameters.add()
>> AttributeError: Writing to ID classes in this context is not allowed:
>> Armature, Object datablock, error setting PoseBone.
>> ----
>>
>> It appears to be caused by a change in the Python API (this code
>> worked before).  It seems that ID classes can no longer be written to
>> within the draw method of Panels.  What is the benefit of this
>> restriction, and why do we need it?
>>
>> And in the mean time, can we please revert that restriction so that
>> Rigify (and possibly other existing code) continues to function as
>> before?
>>
>> For those who are curious: to reproduce the error in Rigify, you have
>> to manually construct a metarig, adding a rig type to a new bone.  The
>> default human metarig does not give this error because of how it is
>> auto-constructed.  The error is emitted to stdout, and does not show
>> up as a python in Blender's UI.  However, it does break Rigify
>> functionality.
>>
>> --Nathan
>
> To follow up on this - Nathan and I discussed in IRC and found a workaround.
>
> Restricting ID writing on draw has been in since 2010, rev33462.
>
> I'm still glad this restriction exists, its too easy to initialize
> data in a panel draw function that then makes the application behave
> incorrectly if the panel happens to start collapsed for example - or
> the tool is accessed from a different part of the interface the data
> may not be initialized.
> Also, manipulating data can cause a redraw, which enters a feedback
> loop using 100% CPU while idle.
>
> At the moment Rigify just has a button to add layers if they are not
> created, ideally blender could support collections that default to a
> non-empty list, but this isn't such a common thing to be doing.
>
> --
> - Campbell
> _______________________________________________
> 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