[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Finishing a paint action.
From: Patrick Julien <freak () codepimps ! org>
Date: 2003-10-09 10:32:42
[Download RAW message or body]
> 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.
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic