Re: The undo stack does not record some changes in layer attributes
Greetings! On Wed, 07 Jun 2000, Sven Neumann [EMAIL PROTECTED] wrote: [quoting Austin Donnelly [EMAIL PROTECTED]] I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. [...] I just had an idea re: the undo stack. It shouldn't matter whether changes are done via keyboard or via mouse. Not pushing an undo on to the stack until the mouse release would help (ie. when adjusting sliders or spin buttons) but only affects mouse operations. The more generic solution is to check the last entry of the undo stack before pushing something on to the undo stack. If someone is nudging a given slider, a check would show that the last operation on the undo stack is a change to that same slider. You would then throw out that stack entry and push the latest change to the stack. This assumes that the operation being done a bit at a time does not affect an image being worked on. If the user nudges different sliders each time, then you would save each nudge of a slider (for example). The tricky part might be to determine whether the last item on the undo stack caused a change to an image. Changes to image previews should probably be ignored. I'm not suggesting this be done for 1.2 as I suspect its too likely to wind up adding bugs to the GIMP. It would help to maximize the use of the undo stack, however.
Re: The undo stack does not record some changes in layer attributes
On Wed, 07 Jun 2000, Sven Neumann [EMAIL PROTECTED] wrote: [quoting Austin Donnelly [EMAIL PROTECTED]] I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. [...] This would not really solve the problem anyway, even if you are using the mouse. Often I play with layer modes and opacity in order to get the effect that I am looking for. So I click on the slider, then select something in the modes menu, then move the slider again, and so on... It would not be a good idea to save all these individual changes on the undo stack, because there are too many of them and I am not interested in saving the current state of the image until I start some painting operations. I still believe that it is a bad idea to waste undo steps for operations that don't save any shadow tiles. How hard would it be to change the undo system so that the number of undo steps is calculated only from "real" undos? What about the idea of merging consecutive changes to the layer attributes into one? Here is my proposal: save and restore all layer attributes (opacity, mode, keep trans, visibility) together with any operation that is currently put on the undo stack. This means that if you do anything that starts an undo step (e.g. painting in the image), the current attributes of all layers are saved on the undo stack. After finishing your painting operation, you can modify the visibility or mode of any layer and nothing will be saved on the undo stack... until you start another undoable operation and then the current layer attributes are saved again at the same time as the new undo step is created. Later, if you undo the last operation, then the image is restored and simultaneously all layer attributes are reset to the values that they had before. I think that such a behaviour would be acceptable to the users. It would also fix the bug that I described earlier and that is affecting the undo-aware scripts, because undoing the changes to the image would also restore the layer attributes to a sane state (as they were before the script was called). The annoying problem with the current code is that if you perform several operations on an image, then change the attributes of some layer, then undo some of all of these operations, you get an inconsistent result: the tiles of the image are as they were before you applied all these operations, but the layer attributes are still in the same state as after the last operation. This is not easy to explain to the users... -Raphael
Re: The undo stack does not record some changes in layer attributes
Hi, Anyone else want to comment at this stage? As a user, would _you_ get confused when you hit undo and all that changes is (eg) the layer opacity? I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. We could think about merging consecutive undo steps into one, but this wouldn't work well for paintstrokes for example. Another possibility would be to take only those undo-steps into account that save tiles. All other undo operations should consume so little memory that they can be safely ignored. Salut, Sven
Re: The undo stack does not record some changes in layer attributes
Hi, I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. This could be done by pushing a group start on mouse down, and closing it on mouse up, for example. Gtk+ is already prepared for that. Changing line 420 in app/layers_dialog.c to gtk_range_set_update_policy (GTK_RANGE (slider), GTK_UPDATE_DELAYED); should do the trick without any fiddling with events. I still believe that it is a bad idea to waste undo steps for operations that don't save any shadow tiles. How hard would it be to change the undo system so that the number of undo steps is calculated only from "real" undos? What about the idea of merging consecutive changes to the layer attributes into one? Salut, Sven
Re: The undo stack does not record some changes in layer attributes
On Wed, Jun 07, 2000 at 04:25:49PM +0200, Sven Neumann wrote: I still believe that it is a bad idea to waste undo steps for operations that don't save any shadow tiles. I agree. If I'm on a machine with limited resources and have the GIMP set up for only, say, 8 levels of undo, I don't want to lose the ability to undo image changes just because I toggle a few layers on and off. The undo history dialog should probably note which actions count as "undo levels" and which don't. Also, it would be nice to be able to force a tile-changing undo (e.g. with Ctrl-Shift-Z) ... if you do 30 layer moves/visbility changes then you probably don't want to have to hit Ctrl-Z 30 times just to undo your last pixel change. The undo history dialog helps with this but I'm not sure I want to have it up all the time. Regards, Tom -- -- Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ -- "We promise according to our hopes, and perform according to our fears." -- -- Francois, Duc de la Rochefoucauld
