[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

[Kalle-Samuli Riihikoski]

Hi!


I'm writing 3d-Coat Applink Addon, and this limitation was really harsh for
my script.
I'm not so skilled programmer in python and I finally got the scirpt as a
stable level.
Now it's broken again. Right now my biggest error is this: Runtimerror:
written in Scene variables not possible.

Right now I use a lot User Scene variables and they changes according info
in 3d-coat panel settings.
What would be the best way to do it because right now it dosen't work.

Thanks.

2010/12/8 Doug Hammond <doughammond at hamsterfight.co.uk>

> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>