[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33462] trunk/blender/source/blender/ python/intern/bpy_rna.c: disallow setting RNA attributes while drawing, this is bad practice so enforcing here has the benifit of making sure

Brecht Van Lommel brechtvanlommel at pandora.be
Wed Dec 8 10:49:48 CET 2010


On Wed, Dec 8, 2010 at 9:49 AM, bartius crouch <bartius.crouch at gmail.com> wrote:
> What might be helpful is to have an example of recommended practice.
> Speaking for myself: right now it's often a matter of experimentation to get
> things to work and this might result in solutions that depend on bad
> practice.

We do need documentation on this, and there's still some hooks
missing, it may be useful to collect feedback from add-on developers
on this topic.

> For example, if you wish your add-on to display a panel with a custom value
> depending on what scene you are in, it would seem logical to add a custom
> property to the Scene ID class.
> Initialising this property from within the panel draw code is bad practice,
> but what to do? Initialising upon registration fails when the add-on is
> enabled and saved to the default .blend (context doesn't exist yet when
> add-on is run at startup). And not initialising of course results in an
> error when the panel (displaying the custom property) is drawn.

It depends on the situation. Typically, you would just set a suitable
default property value on registration. If the value of that property
somehow is based on other data in the scene, that's more complicated.
Then it also depends if it's a user editable property (this case is
rare internally), or some kind of internal add-on data or cache that
doesn't need to be saved to file.

Generally I think context is not something you should need to
initialize a property, it indicates the location where you are in the
user interface and the data that is relevant to it.


More information about the Bf-committers mailing list