[Bf-committers] UI/RNA question

[Jason Wilkins]

In the future I'd like to be able to paint and sculpt at the same
time.  Maybe it would be better if you made paint_mode into a set of
bit flags?  Right now the brushes could be exclusive to one mode, but
in the future they could be combinations.  Am I thinking too far
ahead?  It would effect how you check the paind_mode, using & along
with ==, which may be extra trouble if we decide in the future to
combine capabilities in a different way.  Also, a lot of combinations
make no sense, like sculpting and weight paint...

Perhaps better to go with something simple until this is worked out.



On Fri, Feb 17, 2012 at 3:51 PM, Nicholas Bishop
<nicholasbishop at gmail.com> wrote:
> While looking into this, I ran into the issue that currently you can't
> tell which brush tool is in use with only a brush pointer -- it could
> be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
>
> I can see a couple possible solutions:
> 1) Simplest change is to have separate capability properties for the
> different modes. Maybe have three nested structures in Brush RNA --
> SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
> Each of these then gets boolean properties indicating support for
> direction, stroke methods, etc.
> 2) As an alternative, we could change brushes to only be active in one
> paint mode at a time. I've posted a patch
> (http://codereview.appspot.com/5671088/) that does this. This feels
> simpler to me, don't see that much value right now in having brushes
> be accessible from different paint modes.
>
> Thoughts?
> -Nicholas
>
> On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
>> I agree and this was the direction I wanted to go.  My name for it was
>> going to be "brush semantics."
>>
>> Rather than have complex checks scattered throughout the code it would
>> be better to have something like, for example:
>>
>> isBrushTypeMove()
>> isBrushIgnoresStrength()
>> isBrushTypeClay()
>> isBrushCanLayer()
>>
>> Basically figure out what the name of the set X is when you say "brush
>> element of set X"
>>
>> I called it semantics because I had some vague idea of some other
>> things that fit the same idea besides Boolean predicates.
>>
>>
>>
>> On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>> +1 for adding readonly, boolean properties (as proposed) rather than
>>> checking brush type all over.
>>>
>>> when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
>>> these kinds of checks tend to get out of sync (devs modify in one
>>> place but not others), if they can be generalized into bool props this
>>> should be less error prone and more readable too.
>>>
>>> On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>>> Hi.
>>>>
>>>> You can define RNA prop which isn't "connected" to any DNA property and
>>>> just write your own get/set function for it. Think it'll be much easier to
>>>> just point into sources rather than telling the same here.
>>>> So, you can open rna_tracking.c file and near line 963 you'll see a
>>>> definition of "select" property. It doesn't have DNA
>>>> analog.Functions rna_trackingTrack_select_get
>>>> and rna_trackingTrack_select_set are used to get/set vallue of this prop.
>>>> Think you shall just set NULL instead of set function and clear
>>>> PROP_EDITABLE flag for you prop. And in get function it'll be just
>>>> something like return ELEM(brush->type, CLAY, etcetcetc)
>>>>
>>>> Thinks it'll be easiest way for you and will help keeping py code clear and
>>>> easy to follow.
>>>>
>>>> On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
>>>> <nicholasbishop at gmail.com>wrote:
>>>>
>>>>> I was looking today at updating the menus in sculpt/paint modes,
>>>>> currently they are incomplete.
>>>>>
>>>>> In sculpt especially right now, the toolbar UI has a lot of code like
>>>>> this: "if tool in {'CLAY', 'FLATTEN', 'FILL', ...}". I'd rather not
>>>>> duplicate such code for menus. One option is to add more functions to
>>>>> properties_paint_common.py, but I was wondering if it would be better
>>>>> to make this information available through RNA? E.g. add read-only
>>>>> boolean properties like "has_direction", "has_stroke_method", etc,
>>>>> with a get function to check current tool and such.
>>>>>
>>>>> Would appreciate guidance as to whether that's appropriate RNA usage,
>>>>> or other options.
>>>>>
>>>>> -Nicholas
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> With best regards, Sergey Sharybin
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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