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 <stuaxo2@xxxxxxxxx> 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 <gg@xxxxxxxxxxx> > To: Chris Mohler <cr33dog@xxxxxxxxx> > Cc: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Sent: Monday, May 11, 2009 8:53:43 PM > Subject: Re: Procedural call to undo? > > Chris Mohler wrote: >> On Mon, May 11, 2009 at 12:31 PM, gg <gg@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > > > > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > -- Sent from my mobile device _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
