paintops

[Schleimer, Ben]

Hey guys,
  I think there is a compromise here somewhere....

> 
> The important problem I understand to be that sometimes paintops need to know 
> something like the copy-from location for the clone paintop -- which is 
> created through an alt-click. Wouldn't the best solution be to add the 
> modifier keys to KisPaintInformation. Then we would have something like this:
> 
> KisPaintInformation. This class should contain the information the tool 
> receives from the stylus: position, pressure, tilt, rotation -- maybe also 
> angle to the previous direction. What we're also missing here are modifier 
> keys: if those are passed through, then we can implement duplicate, for 
> instance, entirely inside the paintop, which should make it possible to use 
> duplicate in the other tools, for instance the line tool. 

The duplicate options can be handled inside KisPaintOpSettings since they are defined before the
stroke starts.

> 
> KisPaintOpSettings and subclasses: these should contain all the settings for 
> the paintop like clone-from location and what to do with pressure. The 
> KisPaintopSettings object is persistent; there is one per input device per 
> tool per paintop and the settings are filled through the paintop settings 
> widget or through the paintop.

Maybe all options in KisPaintOpSettings should be in a hash... then there can be one consistant
method for tools to set/update the options needed.

> 
> KisPainter -- this should know which paintdevice to paint on and several 
> global resources, like fg color, bg color, pattern, gradient. (This falls 
> down when we get more complex settings, such as the blended paint load the 
> user will be able to pickup from the paint mixer. But there the user will 
> drag his stylus through the mixer and the bidi-enabled paintop will pickup 
> the complex color).

This can succeed if more of these options are moved to KisPaintOpSettings and KisPainter is made
simpler. Like have the PaintOp be responsible for deciding what color should be painted at the pos
it is called and then instructing the KisPainter to paint. Likewise, if you want a brush (aka
paintop?) to detect the color underneth, it should grab the colors from the KisPaintDevice and
store those values in its KisPaintOpSettings.

> 
> KisPaintop: persistent through the stroke, draws the brush from position a to 
> position b in whatever way fits the bill. Is initialized with the cached 
> KisPaintOpSettings object and for every stroke a KisPaintInformation object 
> for start and end.
>   

I think that all of the duplicate info can be passed once to the paintop at the beginning of a
stroke. If KisPaintOpSettings is a hash, then the paintop can fetch what it needs once (at the
beginning of the stroke mouseDownEvent), fill in what is missing, and then use the static fields
from KisPaintInformation during the mouseMoveEvent to actually do the painting. Then krita will be
efficient during the stroke and plugin developers can add arbitrary paintop options after krita is
released. 

Do this make sense?

Cheers
Ben