From kde-kimageshop Thu May 31 11:15:53 2007 From: "Schleimer, Ben" Date: Thu, 31 May 2007 11:15:53 +0000 To: kde-kimageshop Subject: Re: paintops Message-Id: <726630.41810.qm () web32013 ! mail ! mud ! yahoo ! com> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=118061019622620 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 _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop