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

List:       koffice-devel
Subject:    Re: koffice/krita/image
From:       "Sven Langkamp" <sven.langkamp () gmail ! com>
Date:       2007-04-29 21:36:45
Message-ID: 478b087a0704291436k7ad6ca02q4fe7a4a5cf83014d () mail ! gmail ! com
[Download RAW message or body]

On 4/29/07, Thomas Zander <zander@kde.org> wrote:
> On Sunday 29 April 2007 20:18:15 Sven Langkamp wrote:
> > On 4/29/07, Casper Boemann <cbr@boemann.dk> wrote:
> > > indeed slangkamp had worked on it a couple of weeks back
> > >
> > > maybe he can tell you more
> >
> > The explanation for this is:
> > Unlike 1.x the redo is called on every commands which is added to the
> > undo stack (due to change to qundostack).
> > Transactions are normally executed imidiately by Krita, so the redo
> > call from the undostack would cause a double redo. To prevent this i
> > put in a check to block the first redo call.
>
> This will fail with compound commands (macros), then. Won't it?
> If someone added another command with this one a parent of the command you
> are artificially blocking, it will not be executed.

No, that is not a problem redo() will be called on all childs
normally. The problem here was that the second command was a member,
so it wasn't automatically handled by the undostack (I shouldn't have
called it "child")

> I think its better to avoid calling redo() on the command directly. I.e.
> let the stack do that.
> Which, btw, is what the design pattern also recommends.
>
> It tends to be better to fix the problem instead of work around it ;)

Strictly following the command design pattern isn't usefull here. In
Krita transactions record changes of a paintdevice (memento pattern).
With normal commands that would mean that every time something is
painted a command would be created.

At the moment I don't see a better solution for this in Krita.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]