[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]

Thanks Campbell. That helped a lot. I was able to make working copy again.
But I think that it
really needs some clean up. Thanks again for pointing the right direction.

2010/12/9 Campbell Barton <ideasman42 at gmail.com>

> @Kalle, looked into the 3D Coat script.
>
> If you really need to modify a data this can always be made into an
> operator the user activates from a button but in this case I think it
> could be avoided.
>
> - Setting the scene to GLSL when the panel first draws (first error) Line
> 57.
> The way it is now, this wont work if the user adds a new scene or
> loads a new file since the global variable is only set once.
> Best not do this, The panel could display a warnings message if GLSL
> isn't enabled and/or a button to switch it on.
>
> For the purpose of getting the script working again this can be commented
> out.
>
> - context / wasactive line 131
> I'm not so clear on this but it looks like the blender object is
> storing the paths for 3D coat, and copying these paths between objects
> depending on which was last active, storing the active path in the
> global bpy.coat3D dict.
>
> Is it really important for each object to have its own paths? - could
> the scene store paths instead.
> or if it is useful to have this on the object, copying the old path
> from the new path be disabled?
>
> Could this be simplified further and make the path/object file naming
> automatic? (Quick Edit projection paint does this).
>
>
>
> On Wed, Dec 8, 2010 at 6:57 PM, Kalle-Samuli Riihikoski
> <haikalle at gmail.com> wrote:
> > 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
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>