Brush spacing / rotate / scale

[Matthew Woehlke]

Boudewijn Rempt wrote:
> On Tuesday 13 November 2007, Matthew Woehlke wrote:
>> It's disruptive to workflow (at least, to people coming from PS and/or
>> GIMP). It also loses the ability to repeatedly overstroke parts of an
>> H/V path. Also, at least in Krita 1.6.1 there is no real-time update as
>> in PS or GIMP.
> 
> Er... I've never seen a real-time update of a stroked path in Gimp or 
> Photoshop either.

Not real-time as in 'as I drag the mouse around I see what I could 
paint', but as in 'as soon as I draw this segment, I see what I have so 
far'. Both PS and GIMP have this; Krita does not. Both PS and GIMP also 
allow mixing lines and freehand, and allow you to determine when to 
"lift the brush" (which has the pleasant side effect of making a 
"polyline tool" redundant); again, Krita lacks this.

Oh, and paying closer attention, there are a *lot* of tools that could 
all be folded into one good path tool.

>> Long answer:
>> The PS/GIMP model cleanly segregates drawing into two aspects: tool
>> function, and stroke placement model. All brush-like tools support the
>> 'shift' stroke placement modifier for drawing lines, polylines, and
>> constraining to an H/V path.
>>
>> Krita does not make this clean separation. We have a number of
>> brush-like Tools (brush, eraser, blur, etc) that support exactly one
>> stroke placement method. In addition, we have two "tools" that impose a
>> different stroke placement method but only support a small subset of
>> Tools. Instead of a consistent and complete hierarchy, we have two
>> independent "tool trees", one that starts with function and only
>> supports one method of stroke placement, and one that starts with stroke
>> placement and provides only a subset of functionality.
> 
> Actually, that's not correct: we have a set of stroke placement methods
> (freehand, line, ellipse, rectangle, in 1.6 path) and a set of stroke methods
> (brush, pencil, eraser etc.) that work with all stroke placement methods. The
> former we call tools, the latter paintops in Krita. All paintops should work
> with all painting tools. There are two exceptions in 1.6: painting with 
> filters and duplicate, and those are paintops in 2.0, too.

Whee. Ok, so the hierarchy is really three deep; what the brush looks 
like, what happens when you use the brush, and how strokes are placed. 
And it sounds like the division is still muddied.

IOW what I would expect "eventually" is the regular paintbrush, the 
'pencil' brush, 'digital airbrush', "camelhair brush", "real airbrush", 
"calligraphy pen", etc. Then I'd like to be able to paint "plain", bidi, 
clone, filters, watercolor, etc. with each. It sounds like you are 
indeed moving this way code-wise.

I still disagree with stroke placement being the tools; it makes Krita 
feel more like a shape-drawing program than a painting program by 
emphasizing the line/polyline/square/ellipse tools, rather than the 
different ways of painting.

Given two paint programs... one has the tools 'brush, line, polyline, 
square, ellipse, polygon and star', one has the tools 'brush, pen, 
airbrush, watercolor brush, chalk, pencil and palette knife'. Which one 
are you going to take more seriously? Krita's toolset makes it look like 
a glorified KolourPaint, and not the high-end artistic 'real media' 
program we want it to be.

I'd much prefer the freehand/line/polyline folded into a modifier key, 
so that /painting/, and not drawing geometric shapes, can properly be 
made the prominent function.

> The gimp path tool is very close to our path tool, with the 
> exception that we don't have a separate stroke dialog but stroke the path 
> with the currently selected paintop. Ideally we'd be able to stroke the path 
> shapes that we get from Flake, but we haven't had time to implement that. For 
> 2.0 we still need to do either that, or port the old path tools plugin. (if 
> we do that, we should consider not removing the path after stroking it, until 
> the user selects another tool.)

Ok, Cyrille already talked about persistence, so I'll just mention that 
I agree that persistence is good. (In PS, you have to explicitly delete 
paths, otherwise they are saved with the document.) Hopefully flake will 
give some nice features here for almost-free :-).

-- 
Matthew
If you can read this, you're too close.