Re: [Gimp-developer] Procedural call to undo?
Hi, On Mon, 2009-05-11 at 16:21 -0400, Rob Antonishen wrote: Now that could be useful. Call it GIMP-IMAGE-STATE-SAVE and -RESTORE possibly. Or push and pop.. Not undo. If push and pop, it should be limited to the state the image was in when the script/plugin was initiated. We call this gimp-image-duplicate. Since this is implemented using copy-on-write, it is actually a rather cheap operation and works nicely if you need to save a certain state of the image for later reuse. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. Exactly. A more accurate description of what I was looking for would be mark this point in the undo stack and revert to the marked undo point. (With an error code if the undo point no longer exists.) -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi, On Tue, May 12, 2009 at 6:48 PM, David Hodson hods...@ozemail.com.au wrote: On Mon, 2009-05-11 at 12:57 -0700, Stuart Axon wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. Exactly. A more accurate description of what I was looking for would be mark this point in the undo stack and revert to the marked undo point. (With an error code if the undo point no longer exists.) This approach seems more reasonable -- if the point to undo to must be explicitly identified (in the same manner that each version of a GIT repository has a unique id), there is no ambiguity involved; you are undoing a specific known part, and if that was already undone, a clear error can be raised. In order to do this, each undo step should have a unique ID. Currently, the GimpUndo structure includes a 'time' field; This might be sufficient as a unique ID if it is precise enough (eg. measured in microseconds) Photoshop has a similar feature called 'snapshots' which is user-accessible. I'm not sure whether that kind of thing is a wise thing to implement. Providing an API to programmatically do such things seems fairly uncontroversial to me, though. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
gg wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. for a moment I thought you had a point there, but then I realised this: users undo because of a qualitative decision (that is not it) or because they messed up (oops). scripts can only use quantitative things to decide on (it is not called computing for nothing) and always move forward, maybe using delete/destroy to clean up the mess they made. I have big apprehensions that a machine script need to touch the users' undo history. I would like to know from David Hodson what he is trying to achieve manipulating the undo stack. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Tue, May 12, 2009 at 6:55 AM, peter sikking pe...@mmiworks.net wrote: I have big apprehensions that a machine script need to touch the users' undo history. I would like to know from David Hodson what he is trying to achieve manipulating the undo stack. I have some doubts myself about the value of undo in scripts. The case is much stronger for plug-ins -- there are lots of them where you could get a cleaner usage path by allowing users to try something and then undo it within the plug-in, instead of having to undo in gimp and then run the plug-in over again for every variation. And because they both use the same PDB, plug-ins and scripts go together: having access to undo within one means having it in the other. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Tue, 2009-05-12 at 07:27 -0700, Bill Skaggs wrote: On Tue, May 12, 2009 at 6:55 AM, peter sikking pe...@mmiworks.net wrote: I have big apprehensions that a machine script need to touch the users' undo history. I would like to know from David Hodson what he is trying to achieve manipulating the undo stack. I have some doubts myself about the value of undo in scripts. The case is much stronger for plug-ins -- there are lots of them where you could get a cleaner usage path by allowing users to try something and then undo it within the plug-in, instead of having to undo in gimp and then run the plug-in over again for every variation. Bingo. I'm the author of David's Batch Processor, and I use Gimp as an image processing engine for that and various other projects that don't behave the way most plugins do. For something that I'm working on, it would be handy to be able to unwind back to a saved state. A preview window won't help, I want to work on the real image. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Mon, May 11, 2009 at 12:31 PM, gg g...@catking.net wrote: peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. Bit shouldn't that really be: get image size/depth calculate target image size if (target size 4GB) resize image ? I agree that Undo should be reserved for human use... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. - Original Message From: gg g...@catking.net To: Chris Mohler cr33...@gmail.com Cc: gimp-developer@lists.xcf.berkeley.edu Sent: Monday, May 11, 2009 8:53:43 PM Subject: Re: [Gimp-developer] Procedural call to undo? Chris Mohler wrote: On Mon, May 11, 2009 at 12:31 PM, gg g...@catking.net wrote: peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. Bit shouldn't that really be: get image size/depth calculate target image size if (target size 4GB) resize image ? I agree that Undo should be reserved for human use... Chris It is not the IMAGE size that matters it's the FILE size. Is there a function that predicts the final size of a jpeg file after compression ?? You may want a script to make a few tries (different compression parameters) and CONDITIONALLY back out the change as a function of the result. that was a trivial example to illustrate that a script may want to change it's mind. It also could be some external events over which the script has no control nor any means of predicting. You are presuming to know a hell of a lot about ALL possible circumstances in saying this is unnecessary. regards ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Now that could be useful. Call it GIMP-IMAGE-STATE-SAVE and -RESTORE possibly. Or push and pop.. Not undo. If push and pop, it should be limited to the state the image was in when the script/plugin was initiated. Though I'd appreciate examples of use case where programatic image state restoration would breake things. -Rob A. On 5/11/09, Stuart Axon stua...@yahoo.com wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. - Original Message From: gg g...@catking.net To: Chris Mohler cr33...@gmail.com Cc: gimp-developer@lists.xcf.berkeley.edu Sent: Monday, May 11, 2009 8:53:43 PM Subject: Re: [Gimp-developer] Procedural call to undo? Chris Mohler wrote: On Mon, May 11, 2009 at 12:31 PM, gg g...@catking.net wrote: peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. Bit shouldn't that really be: get image size/depth calculate target image size if (target size 4GB) resize image ? I agree that Undo should be reserved for human use... Chris It is not the IMAGE size that matters it's the FILE size. Is there a function that predicts the final size of a jpeg file after compression ?? You may want a script to make a few tries (different compression parameters) and CONDITIONALLY back out the change as a function of the result. that was a trivial example to illustrate that a script may want to change it's mind. It also could be some external events over which the script has no control nor any means of predicting. You are presuming to know a hell of a lot about ALL possible circumstances in saying this is unnecessary. regards ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Sent from my mobile device ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Rob Antonishen wrote: Now that could be useful. Call it GIMP-IMAGE-STATE-SAVE and -RESTORE possibly. Or push and pop.. Not undo. If push and pop, it should be limited to the state the image was in when the script/plugin was initiated. Though I'd appreciate examples of use case where programatic image state restoration would breake things. -Rob A. On 5/11/09, Stuart Axon stua...@yahoo.com wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. - Original Message From: gg g...@catking.net To: Chris Mohler cr33...@gmail.com Cc: gimp-developer@lists.xcf.berkeley.edu Sent: Monday, May 11, 2009 8:53:43 PM Subject: Re: [Gimp-developer] Procedural call to undo? Chris Mohler wrote: On Mon, May 11, 2009 at 12:31 PM, gg g...@catking.net wrote: peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. Bit shouldn't that really be: get image size/depth calculate target image size if (target size 4GB) resize image ? I agree that Undo should be reserved for human use... Chris It is not the IMAGE size that matters it's the FILE size. Is there a function that predicts the final size of a jpeg file after compression ?? You may want a script to make a few tries (different compression parameters) and CONDITIONALLY back out the change as a function of the result. that was a trivial example to illustrate that a script may want to change it's mind. It also could be some external events over which the script has no control nor any means of predicting. You are presuming to know a hell of a lot about ALL possible circumstances in saying this is unnecessary. regards I think the whole point of keeping the undo history is that very minor changes can be saved with minimal overhead and quickly undone. Cloning the image could potentially be enormous. Undo is not _necessary_ even in the gui, it's just damn useful. I don't see why all scripts should be deemed to have absolutely no need of this. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Procedural call to undo?
I can find the functions in the pdb to manipulate the undo stack - is there a function call that just does an undo? -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au 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. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au 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. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi David, On Sun, May 10, 2009 at 10:34 PM, David Hodson hods...@ozemail.com.au wrote: On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote: On Sun, May 10, 2009 at 9:37 PM, David Hodson hods...@ozemail.com.au 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Hi David, (OK, that's going to get confusing very fast!) On Sun, 2009-05-10 at 23:39 +0930, David Gowers wrote: 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.) That's true, but how does that make undo different from many other functions? If I have a plugin that attaches to an image and randomly adds or deletes layers, it will also disrupt the worldview of other plugins. I'm not sure that making undo available would change anything. -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
