Re: Undo stack for GTK+ (was: Re: undo in textview)

[Holger Berndt <berndth gmx de>]

On Do, 31.12.2009 14:43, Tristan Van Berkom wrote:

>Right, I'm not sure what you have intrerpreted by nesting commands,
>seems to me you mean, "including a group of commands as a command
>in a new group of commands", thats *not* what I had interpreted as
>"nested commands", 

True. The notation in this whole thread is a bit mixed up; people
speaking of transactions, groups, stack entries, actions etc don't
neccessarily mean the same..

>Seems it would make sence  to GtkAction --> GAction as well.

Similarly for models in MVC widgets, I guess (GtkBuffer, GtkTreeStore
etc).

But I am afraid we're slipping into a meta-discussion here. Maybe we
could talk more specific about how the concrete API for a general
purpose undo stack should look like.

My proposal can be seen in:
http://github.com/hb/gtk/blob/undo/gtk/gtkundo.h
http://github.com/hb/gtk/blob/undo/gtk/gtkundo.c

I menitioned some of the reasoning before. I gave brief reasoning
before, let me repeat the two probably most disputable points:

1. Make it at least possible to "register" undo sets of callback
function:

This is to make it possible to clean up the stack in case a dynamically
loaded module unloads again. Alternatively, this could be done by
giving an ID to each stack entry, but see below


2. Use a procedual approach instead of an object-oriented one,
thus register callback functions as plain C structs 
Possible alternatives would be
- Provide an "Undoable" interface that needs to be implemented by
  classes that want to provide undo functionality
- Provide an Undo base class, and require everything that
  wants to undo being derived from that and override virtual functions

The reason I went for plain structs is that it's cheaper and easier to
use. Pushing items onto the stack is a very common operation, and
should be as cheap as possible. In my understanding, the undo stack is
like a data container, just like a GList or a GNode. Undoability is a
property of functions, of something that has been done, not of objects
themselves. It should also support non-object-oriented programming
styles, that are still commonly used in projects that use GTK+. I don't
see any benefits that justify the expenses and unflexibility of
requireing true objects that implement an Undoable interface.

Holger