Re: Undo and the text widget

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.


Christopher Blizzard

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]