[Bf-committers] UI/RNA question

[Nicholas Bishop]

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