[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

Doug Hammond doughammond at hamsterfight.co.uk
Wed Dec 8 14:47:53 CET 2010


Hi,

I don't think I'm on bf-python yet, I get most dev comms from bf-comitters
and bf-extensions. I will subscribe later.

Regarding a use case: the only one I cannot work around at the minute is to
set an object's colour from the LuxRender material editor. To do this either
requires some sort of RNA link between certain custom RNA properties and the
underlying blender material.diffuse_color property, or perhaps a py
'on-change' callback mechanism. Granted, this function is not 100% essential
for the LuxRender addon to operate, but it does give our users some nice
feedback when setting up LuxRender materials. It will have to stay disabled
until the API is developed further in this regard.

Cheers,
Doug.


On 8 December 2010 09:49, Brecht Van Lommel <brechtvanlommel at pandora.be>wrote:

> Hi,
>
> 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.
>
> Brecht.
> _______________________________________________
> 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