[scribus-dev] Some notes/questions about Scribus internals and my project

[Andreas Vox]

Hi Elvis!

The class UndoState acts more or less as a Command pattern. SimpleState is
more or less a "one-size-fits-all" kind of Command pattern implementation.

We had discussions about undo/redo with one of the GSoC applicants and we
agreed that Scribus should use less SimpleState and more specific subclasses
of UndoState. IIRC it's not necessary to implement the restore method in the
UndoObject in this case.

/Andreas

> -----Ursprüngliche Nachricht-----
> Von: Elvis Stansvik [mailto:elvstone at gmail.com]
> Gesendet: Montag, 23. Mai 2011 12:28
> An: Scribus Development Mailing List
> Betreff: Re: [scribus-dev] Some notes/questions about Scribus internals
> and my project
> 
> Hi Cezary,
> 
> 2011/5/23 Cezary Grabski <czarek at oferuje.pl>:
> >> 2) How does the current undo/redo system work? How do I implement
> >> undoable actions? Will I need to implement one (or several?) new
> >> UndoState classes?
> >>
> > As I made undo for text last time I can answer you what I know about
> undo
> > system in Scribus.
> > It is quite simple in idea - in UndoState are saved changed
> parameteres of
> > item before and after changing. For example for undow moving PageItem
> in undo
> > state is saved its start position and end position. On undo start
> position of
> > PageItem will be restored. On redo end position will be restored
> again.
> 
> Ah, I see. After looking a little closer I see that it is actually a
> variant of the command pattern after all.
> 
> > In implementation undo can be more complicated because in undostate
> only
> > simple variables types can be saved - numbers and strings.
> > So for text undo, where in undostate must be saved text with all
> styles
> > information, I prepare function which return all that information in
> string by
> > "saxing" (like in SLA file, when all information is in human readable
> strings
> > in tagged fashion, lets say semi-XML manner).
> 
> Okay, so it's serialized. Makes sense. Undo/redo really is a
> complicated business :)
> 
> > BTW I think you can dont care about undo at this state of
> developpment.
> > We were live with Scribus without undo for text by years, so we can
> live
> > without undo for tables at the beginning. Undo for tables can be
> added later
> > when all new tables code will be "stable", even by someone else.
> 
> Okay. I think that the table operations should not be _that_ hard to
> make undoable this way. I think they will lend themselves quite well
> to being encapsulated as a set of properties in an undo state. But
> we'll see whether I'll have time for undo/redo then.
> 
> BTW, I _very_ much appreciate how well commented/documented the
> undo/redo code is. Good job there!
> 
> Elvis
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev