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

[Paul Davis <paul linuxaudiosystems com>]

On Wed, Dec 30, 2009 at 6:32 PM, Tristan Van Berkom <tvb gnome org> wrote:

> Particularly point 5, nested transactions; I banged my head around that one
> for a while and finally did not implement this; my interpretation of
> nested transactions
> was something like this:
>  o User initiates action
>  o action goes and modifies data on the model
>  o model data change callback initiates "nested action"

we have very similar instances in ardour. its one of the reasons that
i considered nested transactions, but for now, we have a way to create
transactions "off-stack" and then push them into the undo/redo stack,
which seems to fix the problem. before this, there was a single way to
start a transaction, and it was already on the stack (though it could
be abandoned by default).

> Another thing; one interesting feature not present in all undo/redo
> implementations I've come across
> (as a user of applications in general) that is present in Glade; is
> the ->unifies()/->collapse() methods
> of the GladeCommand; basically it allows you to make abundant changes
> to the same data set
> without making a huge unusable command stack (i.e. Glade uses this for
> instance; to make sure
> that 15 edits to a string property will only show up as one command).

ardour's system features a couple of levels of "objects". A Command is
basically a closure/functor with a few defined virtual methods. An
UndoTransaction inherits from UndoCommand, plus a name and a
timestamp, so that it looks like a unitary command, but it also HAS-A
list of commands that it handles as a delegate - when you call
undo/redo on the transaction, it calls the undo/redo methods for each
command. The user sees only the UndoTransactions, not the Commands
that make it up. As a result, a specific UndoTransaction can consist
of any number of individual steps, some affecting the same object,
others affecting entirely different objects.

Command itself is a pure virtual ("abstract") object;  concrete
examples are MementoCommand which saves/restores the state of any
object with get_state()/set_state() methods (this is the most widely
used in ardour, and its a bit of a problem in terms of efficiency). We
also have DeltaCommand which encapsulates an operation that changes
some state of an object, and DiffCommand which is similar, but
different :)


> Also finally, it would be nice to see this targeted somewhere below
> GTK+ in the stack, would be
> a shame to do all this work and not be able to use it from; say;
> Clutter apps or such...

We use language features of C++ so strongly for our system that its
very hard to imagine ever using one implemented in C.