Brush change based on tablet pressure

[Boudewijn Rempt]

On Sunday 01 January 2006 15:18, Bart Coppens wrote:
> Currently, we only support a single hardcoded brush modification by
> pressure: brush size. It would be interesting to change this into something
> a bit more configurable; an artist might want not only to change shape, but
> also want brush opacity to be dependent on how hard he presses on the
> tablet. The GIMP already does this, so there's always the reason of
> 'compatibility' ;-)
>
> Now my question is where we should add this (if at all for 1.5)? Should
> each paintop have a seperate configuration dialog, like Boudewijn suggested
> on IRC? Or should it be the brush itself that carries such a setting?

From a painters's point of view, the "brush" is the paintop; a KisBrush is at 
its best a kind of potato stamp to use with traditional paint app tools. The 
possibility for programmed brushes is with new KisPaintOps. We might, one 
day, be able to have a KisPaintOp derivative that can handle Corel Painter's 
XML-based brush definitions.

So, I'm very much against extending KisBrush with more programmmable 
parameters; that what I had intended KisPaintOp to be used for.

Of course, we need a kind of gui for handling paintop settings, and I propose 
to use the toolbar area to the right of the paintop selector combo for that.


> I think it might be nice for the user to have (not now, in the future) a
> kind of dialog like the dialog on how KMail and other KDE applications let
> you add a configurable list of 'filter actions'. Each paintop (or not,
> maybe a generic list suffices?) could have a list of "actions", like for
> example "scale", "opacity", "color darkness". Then the user could have a
> dialog that lets him add as much 'rules/actions' as he wants (with
> More/Fewer/Clear buttons, like KMail). For each such a rule, he then can
> select from 2 dropdown lists: tablet input, and paintop action. So, he
> might connect "pressure" to "opacity" and "scale", and at the same time
> connect "rotation" to "darkness". The problem here might be that
> configurability might mean a (slight?) performance loss...

It's a nice idea, but it would make Krita a lot more complicated. I'd suggest 
creating a paintop that implements such a programmable interface. That's the 
level I had intended paintops to be used.

-- 
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/20060101/e73ead43/attachment.pgp