Finishing a paint action.
freak at codepimps.org
Thu Oct 9 07:32:42 CEST 2003
> 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:
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
> > 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.
More information about the kimageshop