Hi David, On Sun, May 10, 2009 at 10:34 PM, David Hodson <hodsond@xxxxxxxxxxxxxx> wrote: > On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: >> On Sun, May 10, 2009 at 9:37 PM, David Hodson <hodsond@xxxxxxxxxxxxxx> wrote: >> > I can find the functions in the pdb to manipulate the undo stack - is >> > there a function call that just does an "undo"? >> >> No. >> Although this might conceivably change in the future as GIMP integrates GEGL. > > What does it have to do with GEGL? There's already an undo button there, > it just needs to be connected to the API. No it doesn't (in fact, I'm sure a few GIMP developers might argue that it definitely needs to NOT be connected to the API (ie. stay as it currently is)). This has come up before, to the response essentially 'why would we court trouble by implementing such a thing?' While it *could* be connected to the API, that would introduce various logical inconsistencies (for example, plugins could not rely on having a sensible image state because other plugins (running concurrently, or called by the plugin itself) might roll back the image state. Then the user can still make sense of the image state, but the plugin has no idea what it is, it could be anything. This is particularly bad if a crash is happening, as it also reduces your ability to correctly deduce the cause of the crash.) GEGL would allow a graph-based image structure, in which conventional plugins might not be needed (rather, new GEGL Operations could be implemented via a much simpler type of plugin.) This might help address the above concerns, as well as helping to support more sophisticated undo/versioning structures than our current 'piece of string' model, like trees. Hmm, I take it back, GEGL would not help the likelihood of such a thing being implemented.. it's just a Bad Idea. For just the same reasons that Global Variables are a bad idea. As the Zen of Python says: Explicit is better than implicit. Complex is better than complicated. In the face of ambiguity, refuse the temptation to guess. If the implementation is hard to explain, it's a bad idea. David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
