The manifold meanings of 'depth'

[Boudewijn Rempt]

On Wednesday 02 February 2005 15:27, Casper Boemann wrote:
> Hi
>
> Before coding too much shouldn't we talk this through.

I find that generally a mixture of code and conversation gives the best 
results :-).

>
> We all pretty much agree that pencil, brush and airbrush are tools. To this
> I would add stamp and fill

I'd like to start from what it is a user does with their mouse or stylus. If 
you make freehand movements and something line-oriented comes out, then it's 
a freehand tool with some kind of specialisation. Stamping, smudging, 
brushing or drawing -- stamp tool, smudge tool, brush, pen.

That excludes the fill, so that should be a separate tool. On the other hand, 
there are several types of fill that fit in naturally in the QToolBox idea.

And that complicates things. Remember that this idea started out with the 
factoring out of the paint ops from the tools so every tool that makes marks 
on the canvas can use every paint op in a flexible way. Now I don't 
necessarily want to expose the internals of Krita to the users, but our life 
musn't get too messy either :-).

> My idea is to exclude line, rect, ellipse etc from the above list, but
> rather define them as auxillary tools (that I choose to call guides) to be
> combined with any of the above tools. Exactly like when you draw you have
> your pencil and a ruler if you draw straight lines. Or a pencil and a
> starshaped stencil.

You could even draw a comparison with the drawer full of masks you need to 
have when you use an airbrush for real. Those should fit in slots in the 
airbrush section.

On the other hand, you'd want to be able to use any of the geometric tools 
with all the other things: no reason why you shouldn't be able to airbrush a 
square, or even airbrush a filled-in square.

If you look at Corel Painter, Photoshop and the painter application that's 
bundled with cheap Wacom pads, you'll see they have all a different solution 
for this problem. 

Corel Painter has a small tool palette with freehand brush, move, select, 
magic wand, crop, fill, text, color picker etc, and a completely unusable 
dropdown with all the various brush definitions organized by type. 

Photoshop has a messy toolbox with drop-out buttons for finer selections. 

The older Painter has a small toolbox with selection, fill, freehand, line and 
some other tools, and a drawer system for the freehand brushes organized by 
brush, pencil, etc., with slots for the ten most used brushes.

> Also regarding the other tool options that now has a docker. I would like
> to see them integrated in our new tolbox. The space may not allow it
> directly, but then perhabs the docker could pop up from the toolbar when
> the moused is moved over an icon or something like that.

I was thinking of either having a tool properties widget under the QToolBox, 
or a separate docker, also placed left with the tool/paint op options.

> Regarding the color chooser. Opposite photoshop (and clones) I don't think
> color should be part of the toolbox. In real life you have a palette and a
> toolbox. So for me the colordocker is the natural way (as we have it now).
> The color picker should be a temporary helpertool/mode of the color chooser
> and not a tool in itself.

That's a good idea, I think. Remove the color picker from the tool palette, 
and add it to the color docker.

> The brushes are kind of inbetweens. The true images (like the green pepers)
> should go into options for the stamp tool. The pencil tools should have
> size and hardness as options, and they should tear down when used until you
> sharpen them (this should be optionally though) The brush tool should have
> brushes defined by size and shape and hairlength, not by images.

We don't have real brushes yet, just potato stamps in an aliased and 
anti-aliased variety... It's going to be a challenge to fit real brushes in 
Krita's current architecture, too :-(.

There's been some pretty interesting research in simulating pen & ink, Chinese 
brushes, pencils and chalk recently. The Gooch and Gooch book I mentioned on 
my blog is a good starting point. Particularly the sumi-e stuff looks easy to 
do.


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050202/9437d647/attachment.pgp