Re: Generic undo stack for GTK+

[Tristan Van Berkom <tvb gnome org>]

On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt <berndth gmx de> wrote:
> On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
>
>> Easy Undo/Redo framework are usually based on Inheritance...
>
> I don't have any statistics, but surely, there are many frameworks
> based on inheritance, and many others that aren't. The question is
> more: Does it make sense to base it on inheritance (or interfaces)?
> What is gained by the additional complexity and cost? Personally, I
> don't think inheritance makes sense here. It's not an object that is
> undoable, but a function.
>
>> Anyway, i don't see the value of adding it to GLib, as undo
>> frameworks are only an abstraction, and users end-up doing the
>> painfull job of implementing undo commands for every type of objects
>> or actions they are putting in the stack or the tree.
>
> Aeh -- it's a container type. Of course no generic container type
> gets any application specialized functionality for free. Nobody claimed
> that.
>
> What it does get you is other things, for example
>
> - Your stack will behave consistently with other applications using the
>  same stack implementation.

This is entirely speculative, so far undo/redo implementations are
highly contextual to the needs of the application in question, even
if a common framework were developed thats not to say the feature
sets offered by applications would not differ (or even the menu-items
or accelerators used to fire undo/redo).

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

This would be at the cost of the sanity of the code written for GTK+
applications - it would be a direct encouragement to stab yourself
in the foot with a bad design early off in your project.

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.

> - You don't have to write the boring boiler-plate code yourself, which
>  is likely to motivate application developers to actually offer undo
>  in their applications.

Having a set of interfaces to let the user define undo/redo might
help people make good design choices before setting out to implement
it, granted.

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.


Cheers,
          -Tristan

>
> (As an semi-off-topic side note concerning the last point, I'm quite
> impressed on how the inclusion of the GtkInfoBar widget has positive
> implications on general GTK+ application usability. Having that kind
> of stuff just available does make a difference.)
>
> Holger
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>