Footprint algorithms: in the stamp, or in the paintop?

[Matthew Woehlke]

emanuele at valinor.it wrote:
> But, as said on IRC, this design proposes another thing that should be  
> discussed and makes the difference a bit bigger.
> 
> Now, we use manipulator to retrieve the "final" stamp that will be  
> handled, if needed, by the paintop. The fact is in the current code,  
> the "part" of the manipulator is done by single paintops:
> 
> 1) KisBrushOp "manipulates" the source stamp to get the behavior of a brush
> 2) KisPenOp "manipulates" it in another way
> 3) KisBidiOp will manipulate it in still another way
> N) Each KisPaintOp manipulates the source stamp as it wants.
> 
> This has the drawback that each manipulation algorithm is tied to a  
> particular paintop instead of being separate from it, that's why the  
> idea of the manipulator has come.

...except that I'd rather have KisBrushStamp (the natural bristle brush, 
mind), KisDigitalStamp, KisPixmapStamp, etc :-).

But maybe this is just me complaining about the name "manipulator" (if a 
stamp is a data class and not a code class as I previously understood). 
This looks like maybe it is the case from the pseudocode?

> What I propose is this:
> 
> 1) Make the manipulation, as said before, separate from the paintop  
> and just "retrievable" if needed.
> 2) Introduce a KisDrawingOp, that just takes the manipulated stamp and  
> draw it onto the canvas.
> 3) Keep KisPenOp and KisBrushOp, if needed, to give more control on  
> the manipulations (but I think that they can be completely substituted  
> by manipulators + KisDrawingOp + eventually KisDynamicOp)
> 4) From now on, KisPaintOp will not handle manipulations of the stamp,  
> it will handle things like bidi operations, colorsource generations  
> and so on.

Yup, exactly what I proposed...

Or to reply to "This way, all paintops can access all manipulators. This 
way, we can have just *one* paintop that just paints: it uses the
current manipulator to paint natural brush footprints, autobrushes, gimp
brushes, and so on"; yes, yes, /yes/...

Maybe it would make sense to explicitly exclude colored footprints from 
this, or to move pigment color explicitly into the stamp/dab/whatever 
(hmm, might work) but pigment properties stay in the paintop... except 
that means nothing to filter paintop, etc.

Honestly, I don't see colored stamps making sense with natural media 
(and they don't apply at all to natural airbrush, bristle brush, etc), 
so I think I vote we leave that as-is, but have everything else as 
paintop(pigment, stamp(toolpath)). (Recall that stamp contains anything 
from toolpath we need.) So we do some of each; leave the current 
"digital brush" alone for now, but build the natural-media brushes with 
this model. Later we can make a "digital" stamp that works with 
autobrush, pixmaps, etc, but without color.

-- 
Matthew
That said, if this is coming out of your posterior then you should 
consider your diet. -- Richard Moore, in response to Aaron Seigo's 
stated source of suggested enum values.