Re: Undo and the text widget

[Christopher Blizzard <blizzard redhat com>]

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.

Sorry about that.  What I'm talking about is having the ability to build 
a transaction manager around the text widget without the management of 
those transactions being part of the text widget itself.  When there's a 
change in the text widget a signal is emitted that describes the change. 
 I guess this could be from a selection being pasted, someone adding a 
character or deleting one or someone changing tags.

You could emit those actions in such a way as they would always have a 
direct opposite ( cut vs. paste, add vs. delete, add mark vs. delete 
mark ) and generic enough so that they can used at any time, not just as 
part of a transaction.  You could probably do this kind of thing right 
now if you knew a lot about the API.  For example, if someone deleted a 
character at offset 5 you could back it out by adding a character back 
at that offset.  However, it requires that the transactions that come 
out of the widget go back into the widget through a very different 
mechanism.  I guess what I'm suggesting here is an equally generic 
mechanism for getting those transactions back into the widget.

You say above that operations like "cut" and "meta-space" are done in 
the view widget.  Does this mean that the view widget is what is 
responsible for managing these transactions that you are talking about 
now?  Is that code the appropriate place for this kind of thing?  I 
never drew a distinction between the view widget and the buffer.

--Chris

--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------