paintops

[Cyrille Berger]

> Since krita is extendible
> for new tools AND new paintops, it seems reasonable to assume that plugin
> developers will want to specify more KisPaintInfo options then is currently
> implemented, both static and dynamic. I can imagine properties that the
> tool changes during the stroke like color...
It's not really the job of the tool to change the color. In Krita the 
separation between KisPaintOp and KisPaintTool is that the tool is in charge 
of the mouvement (the where), while the paintop is in charge of how the 
canvas is affected (the how or the what).

I don't think that we reduce the creativity of plugins developers with such a 
system :)
dynamic settings -> KisPaintInfo and there are only a few of them, user input 
is limited
static settings -> extensible by deriving KisPaintOpSettings

> > > PS. an alternative is to for the tool send an inherited class of
> > > KisPaintInfo and have the paintOp use dynamic_cast<> to try to get the
> > > correct type.
> > >
> > > PSPS. Another alternative is for the tool to populate the properties of
> > > the paintOp directly instead of going through KisPainter. This means
> > > the tool needs to do dynamic_cast on the paintOp.
> >
> > The real alternative is to have offset/healing in a
> > KisConfigurationPaintOp.
>
> What? confused here...
KisConfigurationPaintOp is used to hold "static" information (and it's called 
KisPaintOpSettings :) ), see 
http://websvn.kde.org/trunk/koffice/krita/plugins/paintops/defaultpaintops/kis_brushop.cc?revision=667086&view=markup
and 
http://websvn.kde.org/trunk/koffice/krita/plugins/paintops/defaultpaintops/kis_brushop.h?revision=667086&view=markup

In 1.6, you can see it in action with the smudge paintop.

> I guess the correct behavior is to set static options in the paintOp during
> the press event.
>
> After looking at KisToolBrush in krita 1.6, it seems more reasonable for
> the tool to upcast the paintOp, set the static and dynamic paint options,
> set the paintOp inside the painter and then call the painter's drawLine,
> paintAt, etc methods without passing any paint info through the paint.
> Then the painter is only resposible for calling the paintop at the correct
> position.
The problem is that no tool should be have inner knowledge of which paintop is 
in use. Or else it would completely breaks the point of the seperation.

-- 
Cyrille Berger