Re: Generic undo stack for GTK+

[Holger Berndt <berndth gmx de>]

On Mo, 21.06.2010 14:48, Tristan Van Berkom wrote:

>> - Your stack will behave consistently with other applications using the
>>  same stack implementation.
>
>This is entirely speculative, 

What I meant by consistent behaviour was the undo stack policy (e.g.
conventional against emacs-style). This would be consistent for any
user of the stack.

>(or even the menu-items
>or accelerators used to fire undo/redo)

The branch that I was talking about offered GtkActions for undo and
redo, so those would be consistant too. Unfortunately, GtkActions live
in GTK+, so that might not be the best way to go.

>so far undo/redo implementations are
>highly contextual to the needs of the application in question, 

Again, we are talking about a container type. The specific use of a
GList, what is stored and how it is interpreted, is up to an
application. It does make sense to have a generic doubly-linked
list container in glib nonetheless.

>> - Undo could be introduced in GTK+ itself (e.g. TextView/TextBuffer).

[...]

>You don't want your business logic driven by your onscreen widgets
>haphazardly this way - you need your undo/redo stack to interface with
>your internal data model - and you want your views to be synchronized
>to the model.

Yes. In the case of TextView/TextBuffer, the undo stack would be
associated with the GtkTextBuffer, and the GtkTextViews would be
synchronized to the model. I don't see the problem here.

>Although the time it takes to define such interfaces and undo
>mechanics is negligible in comparison to the time needed to properly
>analyze the particular requirements for an application like the Gimp or
>Glade for instance. Not to mention the time debugging all the intricate
>client code that manages interdependent transactions on the abstract
>client data model - all this client code that defines each transaction
>still needs to be written, and that's generally a challenging task.

This paragraph is very true, but not only for undo stacks, but
basically for all container types.

Holger