[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

[Campbell Barton]

@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