<div dir="ltr"><div>though using names we can avoid unwanted edits when mirroring, the problem stays on copy/paste, so I think the conversation you started is indeed worth attention. Having read-only properties to store values that only should be generated might be a good idea<br><br></div>Paolo<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Paolo Acampora, <a href="mailto:palucam@gmail.com" target="_blank">palucam@gmail.com</a><br>M +44 (0) 7474 009566<br><a href="http://uk.linkedin.com/in/paoloac" target="_blank"><span><span>uk.linkedin.com/in/</span><span>paoloac</span></span></a><br></div></div></div></div></div>
<br><div class="gmail_quote">On 13 November 2015 at 12:18, Juan Pablo Bouza <span dir="ltr"><<a href="mailto:jpbouza@hotmail.com" target="_blank">jpbouza@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div dir="ltr">Yeah, I don't know, maybe Paolo is right, if this is used in other softwares and it is kind of a convention it might be just ok. Maybe it should be documented somewhere, I really had no idea Blender did this. So, I don't know if it is worth making things more complicated in the Blender code, I guess I should fix the namings of the properties.<div><br></div><div>In other words, that's why I started this conversation, if there are users using this feature, let's just keep it, I'll adapt to it :)</div><div><br></div><div><br><br><div><hr>Date: Fri, 13 Nov 2015 10:44:21 +0000<br>From: <a href="mailto:palucam@gmail.com" target="_blank">palucam@gmail.com</a><span class=""><br>To: <a href="mailto:bf-animsys@blender.org" target="_blank">bf-animsys@blender.org</a><br>Subject: Re: [Bf-animsys] Bones mirroring properties<br><br></span><div><div class="h5"><div dir="ltr"><div>Just adding my two cents, in my experience I've never seen this as a problem, and the standard practice (not just in blender but also in maya and any other software) is keeping the same name on properties which you wish to be mirrored, and using side prefix/suffix on the ones that should be left alone. I don't think blender is being too intrusive in trying to mirror these values, as while you can just avoid it with proper naming but there would be no way to make it happen if the software would just stop considering custom properties, leaving the users who need such behavior in the wild for no really good reasons. Also what is being proposed in the end is for blender to mangle with names internally, i.e. doing the most simple thing (proper naming), in the hardest possible way (hard coded values).<br><br></div>Cheers<br></div><div><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">Paolo Acampora, <a href="mailto:palucam@gmail.com" target="_blank">palucam@gmail.com</a><br>M <a href="tel:%2B44%20%280%29%207474%20009566" value="+447474009566" target="_blank">+44 (0) 7474 009566</a><br><a href="http://uk.linkedin.com/in/paoloac" target="_blank"><span><span>uk.linkedin.com/in/</span><span>paoloac</span></span></a><br></div></div></div></div></div>
<br><div>On 13 November 2015 at 10:17, Sybren A. Stüvel <span dir="ltr"><<a href="mailto:sybren@stuvel.eu" target="_blank">sybren@stuvel.eu</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><span>On Friday 13 Nov 2015 17:07:55 Joshua Leung wrote:<br>
> So, where to from here? We clearly need some way of distinguishing between<br>
> the two cases. The question is how we should go about this:<br>
>   A) Add a flag of some sort that needs to be set when defining custom<br>
> properties to say whether they're for "internal" use<br>
<br>
</span>I would never use the word "internal" for this. It implies a certain<br>
perspective, a point of view from which you observe things. Does "internal"<br>
mean "internal to Blender" or "internal to some addon"? In the former case an<br>
addon developer shouldn't touch it/go there/read about it, whereas in the<br>
latter it is extremely useful.<br>
<br>
If I were to choose between a label "internal" and "external" I would even<br>
suggest "external" for the use you describe, so there you have a nice example<br>
of the term's subjectiveness.<br>
<span><br>
>   B) Adopt an informal convention (similar to the "DEF_" and "GEO_"<br>
> prefixes used already in many rigs) for tagging properties<br>
<br>
</span>This has the advantage that we don't need extra flags in the GUI. The downside<br>
is that people have to know more by heart to make things work. That means it<br>
needs to be documented well, and lots of things need to point to that<br>
documentation in order for people to actually read it.<br>
<span><br>
>   C) Have all addons store their settings under a designated "__INTERNAL__"<br>
> or "__SETTINGS__" namespace/property. So, instead of having<br>
>               pose.bones["Bone1"].my_addon.my_internal_data_prop,<br>
>        we now have<br>
><br>
> pose.bones["Bone1"].__INTERNAL__.my_addon.my_internal_data_prop<br>
<br>
</span>A designated namespace might be the best way to go. Let's not use dunder<br>
names, though, as they have a very specific meaning in Python. Something like<br>
"addon_settings" or "addon_data" would be fine I think.<br>
<br>
Then there is the question of attribute vs. keyed access:<br>
<br>
    bone.addon_settings.my_addon.my_internal_data_prop<br>
    bone.addon_settings['my_addon'].my_internal_data_prop<br>
<br>
Lots of data access in Blender works with keyed access for collections, so I<br>
feel this might be a logical choice for this situation as well.<br>
<br>
Cheers,<br>
<span><font color="#888888">--<br>
Sybren A. Stüvel<br>
<br>
<a href="http://stuvelfoto.nl/" rel="noreferrer" target="_blank">http://stuvelfoto.nl/</a><br>
<a href="http://stuvel.eu/" rel="noreferrer" target="_blank">http://stuvel.eu/</a><br>
</font></span><br>_______________________________________________<br>
Bf-animsys mailing list<br>
<a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________
Bf-animsys mailing list
<a href="mailto:Bf-animsys@blender.org" target="_blank">Bf-animsys@blender.org</a>
<a href="http://lists.blender.org/mailman/listinfo/bf-animsys" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a></div></div></div></div>                                           </div></div>
<br>_______________________________________________<br>
Bf-animsys mailing list<br>
<a href="mailto:Bf-animsys@blender.org">Bf-animsys@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-animsys" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-animsys</a><br>
<br></blockquote></div><br></div>