[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Finishing a paint action.
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2003-10-09 9:54:21
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 09 October 2003 01:12, Patrick Julien wrote:

> ok, there are several issues with this code,

Told you so...
>
> 1) invalidate will not do anything here.
> 2) updateCanvas is indeed needed to force the image update
> 3) You have absolutely no reason to put KisPainter on the heap...
>

And the device->anchor()?

> just
> 	KisPainter gc(device);
>
> 	gc.fillRect(x,  y,  10,  10,  KoColor::red);
>
> and you are done.  End() is called by the destructor.

Okay.

> You get the right behavior and you don't leak that memory either.  Look at
> the documentation for boost::shared_ptr, boost::scoped_ptr and KSharedPtr. 
> I work on a massive application, bigger than all of koffice, for my day job
> and we use smart pointers everywhere, guess what?  We don't use delete, yet
> tools like purify can't find leaks in our code proper and the performance
> difference is benign.

I've taken a look at it already, but I am truly very much just beginning with 
C++. The last time I had anything to do with a language with explicit memory 
management was fifteen years ago, with Turbo Pascal. And all that means that 
I'm not even sure what problem these shared and scoped pointers are solving. 
But I don't doubt that I'll get it in the fullness of time. 

>
> Actually, there is more than that, you need to be able to support undo/redo
> too, right?  So you need to start and end a transaction to get back a
> KCommand that you can enqueue.
>

I had rather pushed that issue back for solving when I had solved how to use 
and extend the painter. But would it be something like:

gc.beginTransaction(QString("test"));
gc.fill|Rect(...);
m_doc.addCommand(gc.endTransaction());

Does the painter provide all undo/redo information? If so, what's the 
KnamedCommand subclass for that's present in every tool?

> This is actually a remote KImageIO issue isn't it?  If you run krita on a
> remote display even on a X86, you need an up too date KImageIO otherwise
> the display is broken.

Ah, that means I don't have to worry about that. I'm working against 3.1.4.

-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html

[Attachment #5 (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]