Brush spacing / rotate / scale

[Boudewijn Rempt]

On Thursday 15 November 2007, Matthew Woehlke wrote:

> 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.

Ah, I see what you mean here. You want an update while moving the pointer to 
the place where you're going to set the next knot. In 2.0, Karbon's path tool 
already does that -- so I guess that's going to be really easy to have in 
Krita, too.

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

People keep telling me that. However, rather more people keep telling me they 
are so glad that Krita gives them lines, ellipses, rectangles etc. out of the 
box. So I think we'll keep them for now. 

However, if Sven's current work on making the KoPathShape stroke using Krita's 
paintops works out (and it looks promising) we might indeed cut them out in 
favour of the existing geometric shapes users can drag from the shape 
selector. I suspect we'll have some discussion among the developers about 
that, though.


> 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.

I think it's pretty clear, actually, but it is different from other paint 
applications: there are paint operations (every paintop is its own paint 
engine, varying from stupid gimp/photoshop-like potato-stamping to complex 
real brush simulations), and there are tools that help placing the strokes. 
The tool tells the paintop where to draw, the paintop does the drawing. "What 
the brush looks like" is only relevant for the least interesting subset of 
paint operations. Some paintops use .gbr brushes, others don't.

So: 

* tools determine the location where painting happens
* paintops determine what painting means

That's all...

> 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.

Not really: that would presuppose one painting system. We can have as many 
painting systems as we want. A complete Corel Painter or Photoshop painting 
system can be added as (rather complex, code-wise) plugin.

> 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'm not particularly concerned with that: Krita will have both. Just like 
Corel Painter has both. In Krita, you will choose your paintop -- an ordinary 
paintbrush that uses gimp brushes, or a chinese brush, or a programmable 
brush. The paintop may present sub-choices: the chinese brush has six sizes, 
for instance, and the ordinary brush can have gimp brushes (the gimp-style 
brush selector should actually be part of the paintop option area, not the 
general option area, that's a bit of legacy).

> 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 :-).

It will -- the only thing missing is us calling the flake save routines.


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi