Re: Undo framework
Hi, On Tue, 2007-09-25 at 08:16 -0400, Jody Goldberg wrote: Undo comes with Redo, which is sufficient information to make a replay a modification from a known state. Not necessarily. A common approach to Undo/Redo is to store the information before the operation on the undo stack. Then, when the user decides to undo, you push the information at this point to the redo stack and undo by going back to the saved state. This allows you to Undo and Redo, but it is not sufficient information to replay a modification from a known state. Not unless you actually reached this point by undo operations. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Mon, 2007-09-24 at 09:23 -0400, Jody Goldberg wrote: On Mon, Sep 24, 2007 at 02:41:19PM +0200, Rodrigo Moya wrote: On Fri, 2007-09-21 at 16:21 -0300, Johan Dahlin wrote: I'm not sure we should talk about a 'document' there, there are many operations outside of documents which are undoable. yes, we are not talking only about document, and yes, I think it should be in Glib, except for the widgets that might be needed. Agreed. As for transation-based framework, I'm not sure exactly what Jody is thinking about, but to me, if I understood it correctly, it makes a lot of sense to be able to group performed actions into a set that can be undone/redone and even repeated. That would, probably, fit the GIMP's needs, as stated by Sven, to have nested undo groups. Each group would be a transaction, that can be redone/undone/repeated as a single entity. The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. It seems useful for anything that operates on persistent data, be it a document, or control-center settings. I'm thinking, maybe a crazy idea though, but this could also be useful, once the actions are stored in a file, to be able to repeat/run those actions outside of the application. That is, you could do a set of operations on a document-oriented application, save that to a file, and use that as a sort of 'script' to do the same operations on another document. -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Wed, 2007-09-26 at 13:08 +0200, Rodrigo Moya wrote: [...] It seems useful for anything that operates on persistent data, be it a document, or control-center settings. I'm thinking, maybe a crazy idea though, but this could also be useful, once the actions are stored in a file, to be able to repeat/run those actions outside of the application. That is, you could do a set of operations on a document-oriented application, save that to a file, and use that as a sort of 'script' to do the same operations on another document. dreamy comment I wrote a software updater once that had an undo/redo framework that was stored to a file, we used that to store the current step that was being executed, this way we could properly recover and undo everything if there was any errors, and even recover when losing power (by loading that file and continuing where we left off) /dreamy comment Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Mon, Sep 24, 2007 at 08:32:01PM +0200, Sven Neumann wrote: Hi, On Mon, 2007-09-24 at 09:23 -0400, Jody Goldberg wrote: The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. This would certainly be useful but it is something different than an Undo system. An undo system stores information on how to undo an operation. This typically involves storing data and state information from before the operation is performed. This information allows you to undo the operation, but it typically doesn't allow you to replay it. Undo comes with Redo, which is sufficient information to make a replay a modification from a known state. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Sat, 2007-09-22 at 01:01 +0100, Iain * wrote: Do you allow nested undo groups? This is rather important if you want to compose actions from smaller actions and still allow scripts or other higher levels to combine these into a single undo step. We make heavy use of nested undo groups in GIMP. We allow one level of nesting, I can see your point about allowing deeper nesting though and will think about how it could be done. I suppose this is as much of the merging of actions that should take place, I don't see that the UndoManager itself should support automatic merging as each application has different requirements for when a merge should happen, but if we allow multiple nesting of actions then the applications can merge as they see fit. I can see the reason for the non-UI parts to go in GLib, but is there any precedence in having stuff like this in GLib? If it was to go in GLib it would be its own seperate library, which for one thing would kinda suck? why? we already have gthread, gmodule, glib, gobject, gio As for transactional stuff, I would think that it seems overkill for most applications, although it'd be great if we could work out some way to allow those that want it to be able to implement it on top of the base system. I can't see how you could make it generic enough to make everyone happy. this is easy, if the API provides, for instance, a 3-step mechanism: create_context add_stuff close_context thus, normal apps would just call the related 3 functions. More complicated apps would manage different contexts, and be able to associate a context to another one: set_parent_context for instance -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Mon, Sep 24, 2007 at 02:41:19PM +0200, Rodrigo Moya wrote: On Fri, 2007-09-21 at 16:21 -0300, Johan Dahlin wrote: I'm not sure we should talk about a 'document' there, there are many operations outside of documents which are undoable. yes, we are not talking only about document, and yes, I think it should be in Glib, except for the widgets that might be needed. Agreed. As for transation-based framework, I'm not sure exactly what Jody is thinking about, but to me, if I understood it correctly, it makes a lot of sense to be able to group performed actions into a set that can be undone/redone and even repeated. That would, probably, fit the GIMP's needs, as stated by Sven, to have nested undo groups. Each group would be a transaction, that can be redone/undone/repeated as a single entity. The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. It seems useful for anything that operates on persistent data, be it a document, or control-center settings. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Mon, 2007-09-24 at 09:23 -0400, Jody Goldberg wrote: The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. This would certainly be useful but it is something different than an Undo system. An undo system stores information on how to undo an operation. This typically involves storing data and state information from before the operation is performed. This information allows you to undo the operation, but it typically doesn't allow you to replay it. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
I would find it useful if such an undo system would do away with the stack view of things and use the back-in-time view that Emacs uses. For example, if we have Do A, Do B, Do C, Undo C, Do D then it should be possible to rewind history to the point where C was done. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both have very similar frameworks. Attached are the header files. This is, erm, an entirely different Ross Burton, and I think that this should be added to GTK+. I for one will use it in my application, Tosks. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: Hi, I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both have very similar frameworks. Attached are the header files. Hi, I think that would be a great thing to add to gtk+ if only to encourage software authors to write undoable code - the brief description of the framework pretty much matches the implementation in glade to the letter (we started out with command objects which had undo/redo capabilities... and then found that we needed them to be somewhat recursive, allowing you to group low-level commands together into more powerful highlevel commands). Should be noted here that from my particular experience, writing code that is undoable (i.e. filling in the execute()/undo() routines for a given undoable command) is far more challenging than writing a framework that supports it - but it would be great if a common framework could at least be shared. About GtkEntry... maybe it would be good to take a step back and think MVC, GtkEntry usually effects some internal data in the application - I'd much rather see built-in undoability implemented in say, a GtkTextBuffer that might be viewed by multiple GtkEntries or GtkTextViews... anyway just saying that usually you probably want undo to effect the program's internal dataset, not the widgets that are showing whatever happens to be current. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On 9/21/07, Tristan Van Berkom [EMAIL PROTECTED] wrote: Should be noted here that from my particular experience, writing code that is undoable (i.e. filling in the execute()/undo() routines for a given undoable command) is far more challenging than writing a framework that supports it - but it would be great if a common framework could at least be shared. Defintely. About GtkEntry... maybe it would be good to take a step back and think MVC, GtkEntry usually effects some internal data in the application - I'd much rather see built-in undoability implemented in say, a GtkTextBuffer that might be viewed by multiple GtkEntries or GtkTextViews... anyway just saying that usually you probably want undo to effect the program's internal dataset, not the widgets that are showing whatever happens to be current. Well, Ross and I discussed it. I think his use case is for in dialogs where the internal state of an object doesn't get changed until the dialog is closed, but wants to be able to allow the text entries to be undone in the meantime. The way it works in Cocoa is that entries are undoable until they lose focus. iain ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
David Trowbridge wrote: You might want to look at the undo implementation in Tomboy. It implements the mergeable command idea fairly nicely. Or look at GtkSourceView, or look for it in bugzilla, or look at bunch of other implementations (I am sure there are *plenty*, minimum two in every programming language). I don't know about tomboy's one, but what GtkSourceView has (or the patch in bugzilla, not too far from GtkSourceView's) are not flexible enough either. It just sucks when you want more, when you have textview where text may be modified by different entities without knowing about each other (plugins, that sort of stuff). Undo manager should allow merging and nesting. And ability to move groups/actions around. Please don't say out of the scope, we already have bunch of undo implementations, so it's not just let's have anything. On the other hand, of course, anything would do as a mean to undumbify gtk. If anyone's proposal has chances to get into gtk so I can press Ctrl-Z in xchat, I will vote for it with all my hands and legs even if I will continue using my own implementation in my entries and textviews. Not that my vote matters of course, I'd vote for my patch in that case :) Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. Please consider to add the basic parts to GLib. Otherwise applications with a strict separation of functionality and user interface will be unable to use your undo framework. The basics should go into GLib. UI code such as GtkActions built from undo objects can go into GTK+. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: The basic concepts are that there is an UndoManager object. When you start an operation that can be undone you call undo_manger_context_begin and this returns a UndoContext. Each part of your operation then creates an Undoable setting the functions that undo, redo and destroy it and set some userdata which contains enough information to undo/redo it. These Undoables are then added to the UndoContext. When the operation is finished you call undo_manager_context_end which adds the operation to the undo/redo stack. This sounds similar to the undo system that we use in GIMP. I haven't looked at your code, but it appears to me that your system is somewhat less flexible. Do you allow nested undo groups? This is rather important if you want to compose actions from smaller actions and still allow scripts or other higher levels to combine these into a single undo step. We make heavy use of nested undo groups in GIMP. I am not trying to argue that the GIMP undo system would be suitable for use anywhere outside GIMP. But we might want to adopt a more general undo framework if it is provided by GLib/GTK+ and allows us to implement everything that our current undo system allows us to do. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Fri, Sep 21, 2007 at 05:51:26PM +0100, Iain * wrote: Hi, I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both have very similar frameworks. Attached are the header files. The concept sounds good, and while your implementation looks clean, I'd rather not see it go into gtk in it's current form. 1) As you point out we've all had undo/redo implementations for several years. If we're going to do this, let's skip a generation and support transaction logging rather than just picking a best of breed version of the existing code. It's something I've been meaning to add to gnumeric [1] for several years. The goal is to support a transaction file akin to VIM's .swp. Doing this properly with permissioning for the transact file isn't code that should get replicated in each app. 2) Undo/Redo methods aren't sufficient. We've found it necessary to differentiate Redo and Repeat sometimes. In addition, having written dozens of these objects it feels like the design isn't quite right. There have many instances that required pre-validation. Code that is tightly coupled with the implementation, and should logically live in the same place. 3) Gtk seems like the right place for widgets to display the undo/redo stack. However, the core of the functionality seems non-gui. Something that would belong wherever we chose to put GDocument. To date that type of code has been migrating out of gnumeric and into goffice. If there is interest, we could collaborate on the next generation of this in there and rename to 'libgdocument' or somesuch. [1] http://svn.gnome.org/viewcvs/gnumeric/trunk/src/commands.c?view=markup ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Jody Goldberg wrote: On Fri, Sep 21, 2007 at 05:51:26PM +0100, Iain * wrote: Hi, I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. QT4[1] and Cocoa[2] both have very similar frameworks. Attached are the header files. The concept sounds good, and while your implementation looks clean, I'd rather not see it go into gtk in it's current form. 1) As you point out we've all had undo/redo implementations for several years. If we're going to do this, let's skip a generation and support transaction logging rather than just picking a best of breed version of the existing code. It's something I've been meaning to add to gnumeric [1] for several years. The goal is to support a transaction file akin to VIM's .swp. Doing this properly with permissioning for the transact file isn't code that should get replicated in each app. I tend to agree, with the limited experience I had dealing with undo/redo in Gazpacho I found out that I strongly disliked the way of using commands. However I cannot heartily recommend a transaction based scheme since I only did a very simple prototype for applying GObject properties using transactions. It might end up way to complicated, perhaps someone with experience of implementing a transactional database could add something to this discussion. 3) Gtk seems like the right place for widgets to display the undo/redo stack. However, the core of the functionality seems non-gui. Something that would belong wherever we chose to put GDocument. To date that type of code has been migrating out of gnumeric and into goffice. If there is interest, we could collaborate on the next generation of this in there and rename to 'libgdocument' or somesuch. While I agree that an undo stack should be in Gtk+ or lower I'm not sure a transaction based should go there, but it should be possible to implement one top of the interfaces/manager objects there. I'm not sure we should talk about a 'document' there, there are many operations outside of documents which are undoable. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Do you allow nested undo groups? This is rather important if you want to compose actions from smaller actions and still allow scripts or other higher levels to combine these into a single undo step. We make heavy use of nested undo groups in GIMP. We allow one level of nesting, I can see your point about allowing deeper nesting though and will think about how it could be done. I suppose this is as much of the merging of actions that should take place, I don't see that the UndoManager itself should support automatic merging as each application has different requirements for when a merge should happen, but if we allow multiple nesting of actions then the applications can merge as they see fit. I can see the reason for the non-UI parts to go in GLib, but is there any precedence in having stuff like this in GLib? If it was to go in GLib it would be its own seperate library, which for one thing would kinda suck? As for transactional stuff, I would think that it seems overkill for most applications, although it'd be great if we could work out some way to allow those that want it to be able to implement it on top of the base system. I can't see how you could make it generic enough to make everyone happy. Undo/Redo methods aren't sufficient. We've found it necessary to differentiate Redo and Repeat sometimes. I'm not sure how repeat fits in here exactly, although maybe I'm not thinking of the same thing as you are. I'm thinking of GIMP's repeat filter functionality, and while its similar conceptually, I'm not sure why it is something that the undo manager should be taking care of? iain ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
