Re: Procedural call to undo?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <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
>>
>>
>>

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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux