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/ ------------