Finishing a paint action.

[Patrick Julien]

> And the device->anchor()?

Anchor is for actually freezing the coordinates of the device.  I.e. freezing 
a layer on the display.

>
> > 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.

Automatic memory management.

>
> > 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.beginTransaction("test");

> gc.fill|Rect(...);
> m_doc.addCommand(gc.endTransaction());

That would be the gist of it, unfortunately it won't work if you're using raw 
pixel copies like you're doing right now tho.


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

Hmm, I don't actually remember, but the KCommand's returned from KisPainter 
are only for tile modifications.  There are commands for other, different 
types of actions, for example renaming a layer.

Also, the old tools we're doing all their commands and their undo support 
individually.

>
> > 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.

Yep, the fix was applied to kde post 3.1, not sure anymore, look in kdebugs 
for KImageIO, I know it's fixed tho.