[Bf-animsys] Bones mirroring properties

[Sybren A. Stüvel]

On Friday 13 Nov 2015 17:07:55 Joshua Leung wrote:
> So, where to from here? We clearly need some way of distinguishing between
> the two cases. The question is how we should go about this:
>   A) Add a flag of some sort that needs to be set when defining custom
> properties to say whether they're for "internal" use

I would never use the word "internal" for this. It implies a certain 
perspective, a point of view from which you observe things. Does "internal" 
mean "internal to Blender" or "internal to some addon"? In the former case an 
addon developer shouldn't touch it/go there/read about it, whereas in the 
latter it is extremely useful.

If I were to choose between a label "internal" and "external" I would even 
suggest "external" for the use you describe, so there you have a nice example 
of the term's subjectiveness.

>   B) Adopt an informal convention (similar to the "DEF_" and "GEO_"
> prefixes used already in many rigs) for tagging properties

This has the advantage that we don't need extra flags in the GUI. The downside 
is that people have to know more by heart to make things work. That means it 
needs to be documented well, and lots of things need to point to that 
documentation in order for people to actually read it.

>   C) Have all addons store their settings under a designated "__INTERNAL__"
> or "__SETTINGS__" namespace/property. So, instead of having
>               pose.bones["Bone1"].my_addon.my_internal_data_prop,
>        we now have
> 
> pose.bones["Bone1"].__INTERNAL__.my_addon.my_internal_data_prop

A designated namespace might be the best way to go. Let's not use dunder 
names, though, as they have a very specific meaning in Python. Something like 
"addon_settings" or "addon_data" would be fine I think.

Then there is the question of attribute vs. keyed access:

    bone.addon_settings.my_addon.my_internal_data_prop
    bone.addon_settings['my_addon'].my_internal_data_prop

Lots of data access in Blender works with keyed access for collections, so I 
feel this might be a logical choice for this situation as well.

Cheers,
-- 
Sybren A. Stüvel

http://stuvelfoto.nl/
http://stuvel.eu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20151113/6766ee57/attachment.sig>