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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list