[Bf-committers] UI/RNA question

[Jason Wilkins]

Sorry to double up emails, but after comparing your patch and the same
areas of the code from last summer it appears I ran into a similar
problem and started to solve it in an very similar way.

The main difference seems to be that in your patch you have decided to
make a separate paint mode enum that is mutually exclusive (to the
point of splitting up existing dual purpose brushes in readfile),
while I kept the existing ob_mode flags.

I'd have to look at my commit logs to see exactly what I was trying to
fix.  I think it was as simple as the fact that I wanted new brushes
to only appear in the mode you created them in, instead of being
enabled for all of them by default, so I passed ob_mode in as an
argument and copied it from the scene when creating a new brush.

In my opinion, I like the code in readfile that splits up brushes with
multiple modes.  I'm not keen on creating a new enumeration in C, but
I think it would be great to create a new logical enumeration in RNA
that enforces mutual exclusion for brush->ob_mode in the UI while
remaining compatible with the existing mode flags.  Then we can assume
that a brush is only for one mode.

In the future I'm imagining we won't have something as silly as a
sculpt, texturepaint, and a sculpt+texturepaint mode.  Instead we'd
have a unified mode and the brushes will determine what sub-systems
are used (you'd switch brushes, not modes).  By the time we get there,
whatever we build now will probably be swept away, so it's probably
pointless for me to be holding onto the ob_mode flags as if we
absolutely need them.  But I'd argue that we probably don't need a new
enumeration if we enforce that brush->ob_mode only gets one bit set.

On Sat, Feb 18, 2012 at 4:25 AM, Jason Wilkins
<jason.a.wilkins at gmail.com> wrote:
> I'm looking at onion and comparing it to your patch it looks like I
> did something very similar by adding an ob_mode argument to add_brush.
>
> Maybe that is why I'm confused about what the big deal is since I'm
> probably thinking about the state of onion branch and not trunk.
>
> On Fri, Feb 17, 2012 at 11:23 PM, Nicholas Bishop
> <nicholasbishop at gmail.com> wrote:
>>> If the brush is enabled for both vpaint and sculpt modes then
>>> direction is supported for sculpting.
>>
>> Right, this is indeed fine if we define the properties to be specific
>> to a single mode. Then (in Python) we can do
>> Brush.sculpt_capabilities.direction, or
>> Brush.vertexpaint_capabilities.direction. I was simply suggesting we
>> simplify this down to Brush.has_direction -- a change that would
>> require the brush to know which of its tools is active.
>>
>>> Currently I do not think any brushes should be enabled for multiple
>>> modes because we do not support that.  If a brush has both bits set
>>> then it shouldn't be usable in any mode.
>>
>> Our current default .blend does include brushes enabled in multiple
>> modes (BRDraw is in all modes.)
>>
>> -Nicholas
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers