On Sun, May 10, 2009 at 9:37 PM, David Hodson 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

Hi David,

On Sun, May 10, 2009 at 10:34 PM, David Hodson wrote:

On Sun, 2009-05-10 at 22:03 +0930, David Gowers wrote:

On Sun, May 10, 2009 at 9:37 PM, David Hodson 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

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

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.

On Mon, May 11, 2009 at 12:31 PM, gg 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

Chris Mohler wrote:

On Mon, May 11, 2009 at 12:31 PM, gg 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

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
To: Chris Mohler
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 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

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 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
To: Chris Mohler
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 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

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 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
To: Chris Mohler
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 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.

Hi,

On Tue, May 12, 2009 at 6:48 PM, David Hodson 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

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

On Tue, May 12, 2009 at 6:55 AM, peter sikking 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

On Tue, 12 May 2009 07:27:51 -0700 Bill Skaggs wrote:

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.

Would it not be better in that case to have a preview which could operate on the entire image (as per Curves etc) than to add a step to the process of evaluation... I speak here as a user, it just seems to make more sense to me.

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