From kde-kimageshop  Sat Dec 13 20:51:12 2003
From: Patrick Julien <freak () codepimps ! org>
Date: Sat, 13 Dec 2003 20:51:12 +0000
To: kde-kimageshop
Subject: Re: New Brush Tool!
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=107134868817815

On December 13, 2003 01:39 pm, Boudewijn Rempt wrote:
> On Saturday 13 December 2003 12:37, Patrick Julien wrote:
> > That was the intention behind this model, investigate your brush tool
> > further, there is still probably a bug lurking in there.
>
> Found the problem on the way home from Brussels today: a kmacrocommand just
> makes a list of commands -- in this case individual kispainter commands.
> That's to say, every bitBlt does an addCommand to the KMacroCommand,
> instead of adding the affected tiles to the tile list of the existing
> command.


Well, yes, that is expected behavior.  I believe what you want to it keep your 
painter on the member list of your class... you begin() the painter on 
mousePress (or key, whatever) and end() on release.


>
> I.e.,
> void KisPainter::bitBlt(Q_INT32 dx, Q_INT32 dy, CompositeOp op,
>                         KisPaintDeviceSP srcdev,
>                         QUANTUM opacity, Q_INT32 sx, Q_INT32 sy, Q_INT32
> sw, Q_INT32 sh)
> {
> ...
> 	if (m_transaction) {
> 		tc = new KisTileCommand(m_transaction -> name(), m_device, dx, dy, sw,
> sh); m_transaction -> addCommand(tc);
> ...
> }
>
> I thought it would re-use the first KisTileCommand created for this
> transaction.

No, even if I had wanted to... I have no access to the list of commands inside 
KMacroCommand.

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop