GNOME Bugzilla – Bug 316551
Undo/Redo support for GtkTextView
Last modified: 2009-09-25 03:17:01 UTC
I think GtkTextBuffer needs at least a undo signal, to be able to implement undo actions on the TextBuffer. I would even opt for a complete undo system, with support for TextTags, etc. Other information:
I don't think that an 'undo' signal is worth much, what is needed is real undo support. Unless Matthias/Owen disagree I'm gonna hijack this bug to request full undo support since there isn't such a bug in bugzilla. Some pointers to existing implementations and problems follow, it needs however someone with some time on their hands to sitdown and write the patch. General ------- Undo/Redo support is definately a useful feature for a text widget, not only for a text editor like gedit (which can indeed implement the feature itself) but also in all other text areas used in many other apps. For instance Mozilla/Firefox has undo/redo in its text forms. Existing implementations ------------------------ There are at least three well tested existing implementations of Undo/Redo for GtkTextView which can be used has a starting point for the work. Each one with pro and cons: * the one in GtkSourceView (used by gedit and others) - well tested - alreday in C (easy to move) - only handles undoing insert/delete, doesn't handle undoing apply_tag and other actions - would be nice to add the ability to track a description of the undoable action to use in the UI (see bug 307757) - could use some minor performance improvements (bug 312653) * the one in Tomboy - written in C# - handles apply_tag - it probably requires more memory (or at least a C version would) since each action stores a pointer to the redo function * the one in VMware's libview (view.sourceforhe.net) - written in C++ / gtkmm - afaics doesn't handle apply_tag etc (I may be wrong) - again, as tomboy, it uses a class to represent each action, which is cleaner but more expensive in terms of memory General design issues/questions ------------------------------- - gtksourceview and tomboy separate the implementation in an UndoManager object, this may be useful since gtktextbuffer.c is already pretty big. Beside an undo manager could also be attached to gtkentry etc - if instead we decide to implent inside gtktextbuffer, can we take advantage of the access to the internals? (I'm not sure if it can be useful in any way...) - should the Undo be on by default? Would this break apps implementing undo themselves? - Should Undo/redo be implemented as part of the GtkEditable interface and support for it added also to entries etc? Or maybe even come up with a GtkUndoable interface and let other widgets implement this interface.
The one I now have implemented in the TextView/Buffer OO class in mzgtk2 (for mzscheme). Uses a functional approach to keep the undo history. On buffer change, it creates an inverse operation, using a anonymous function, which it keeps in an undo stack.
Additional info from this thread:http://mail.gnome.org/archives/gtk-list/2009-September/msg00137.html and in this blog entry: http://berndth.blogspot.com/2009/09/chronically-underrated-undo.html There are at least this implementations for undo/redo support: - gundo : http://github.com/herzi/gundo/ - undo_stack: http://github.com/hb/undo_stack *** This bug has been marked as a duplicate of bug 322194 ***