On Wed, Dec 30, 2009 at 6:32 PM, Tristan Van Berkom <tvb@xxxxxxxxx> 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.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
