On 4/29/07, Thomas Zander wrote: > On Sunday 29 April 2007 20:18:15 Sven Langkamp wrote: > > On 4/29/07, Casper Boemann 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