Re: Undo and the text widget

[Alexander Larsson <alla lysator liu se>]

On 28 Nov 2000, Havoc Pennington wrote:

> 
> Christopher Blizzard <blizzard redhat com> writes: 
> > You might want to consider breaking the undo and the text widget
> > into seperate components instead of making the transaction
> > management part of the editor's api.
> > 
> > Is it possible to break the text widget's actions down into chunks
> > that you can play forward and back?  That way you would get redo and
> > undo. You could pass in something like:
> > 
> > "Add" "Type" <char code> "Offset"
> > "Delete" "Cut" <char code> "Offset"
> > 
> > You could also use that to build macroified text actions - it lends
> > itself to scriptability.  You could build the transaction manager
> > around it instead of as a part of the editor.  You could also hook
> > up to the key signals in the editor widget and build your own
> > transactions from that instead of having a hard coded transaction
> > behaviour in the editor widget.
> > 
> > Sorry if this sounds a little disjointed, I'm in a meeting. :)
> > 
> 
> I think I'll need a more slow and patronizing explanation of that
> before it's totally clear to me. I haven't ever implemented this type
> of thing.
> 
> Right now the GtkTextBuffer object has only two real mutating
> operations, which are "insert" and "delete." You might also want to
> undo stuff related to tags and marks, I guess.
> 
> The higher-level operations, such as "meta-space" or "cut" are done
> in the view widget instead of the buffer, using the GtkBindingSet
> stuff that lets people change keybindings from a gtkrc.

There is a gundo widget you might want to look at for ideas.
http://www-dse.doc.ic.ac.uk/~np2/software/undo.html
I haven't looked at it though, so it might suck.

The normal way of implementing Undo/Redo is by making each "change" an
Action. An Action is an abstract representation of the change, and can be
applied and after it has been applied it can be unapplied.
Then when the user runs undo you unapply all Actions since the last time
the user started doing something. This might be done by placing
transaction points in the undo stack, or having an group action which
contains other actions.

Later version of photoshop apparently uses a tree of changes instead of a
stack, which means you can "change a, undo, change b, undo to recover
change a". That means the undo transaction manager and the actions 
probably should be well separated so that the transaction manager
behaviour can be changed.

I think chris also suggest some kind of external text representation of
the actions, so you can create them by hand and apply them from macros and
stuff. I dunno about that, i think they should be very opaque.

/ Alex