Jody Goldberg wrote: > On Fri, Sep 21, 2007 at 05:51:26PM +0100, Iain * wrote: >> Hi, >> >> I've had an undo framework in Marlin for years now, but recently >> people have been using it in other things (notably Ross in Tasks - ok, >> actually, he's the only one) and we discussed suggesting this for >> inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both >> have very similar frameworks. Attached are the header files. > > The concept sounds good, and while your implementation looks clean, > I'd rather not see it go into gtk in it's current form. > > 1) As you point out we've all had undo/redo implementations for > several years. If we're going to do this, let's skip a > generation and support transaction logging rather than just > picking a best of breed version of the existing code. > It's something I've been meaning to add to gnumeric [1] for > several years. The goal is to support a transaction file akin to > VIM's .swp. Doing this properly with permissioning for the > transact file isn't code that should get replicated in each app.
I tend to agree, with the limited experience I had dealing with undo/redo in Gazpacho I found out that I strongly disliked the way of using commands. However I cannot heartily recommend a transaction based scheme since I only did a very simple prototype for applying GObject properties using transactions. It might end up way to complicated, perhaps someone with experience of implementing a transactional database could add something to this discussion. > 3) Gtk seems like the right place for widgets to display the > undo/redo stack. However, the core of the functionality seems > non-gui. Something that would belong wherever we chose to put > GDocument. To date that type of code has been migrating out of > gnumeric and into goffice. If there is interest, we could > collaborate on the next generation of this in there and rename to > 'libgdocument' or somesuch. While I agree that an undo stack should be in Gtk+ or lower I'm not sure a transaction based should go there, but it should be possible to implement one top of the interfaces/manager objects there. I'm not sure we should talk about a 'document' there, there are many operations outside of documents which are undoable. Johan _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
