[Bf-committers] Python API change breaks Rigify

Campbell Barton ideasman42 at gmail.com
Sun Feb 17 05:32:12 CET 2013


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


More information about the Bf-committers mailing list