Re: Undo framework

Jody Goldberg wrote:
On Fri, Sep 21, 2007 at 05:51:26PM +0100, Iain * wrote:

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.


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