On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt <bern...@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 > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list