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
Hi, > 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. This sounds extremely similar to our proposal for the Undo system of Gimp-2.0, where we will record changes to the context together with the Undo information. The question is: do we really want to make this change now? This won't be trivial and is likely to introduce new bugs. We could have a 1.2 release this month, or we start to hack the undo system now and end up doing similar changes until the end of the year. Is this change worth that effort? Salut, Sven
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: [gimp-devel] Re: The undo stack does not record some changes in layer attributes
Tom Rathborne ([EMAIL PROTECTED]) wrote: > 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. Agreed... :-) > 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. This comes very close to the idea of micro- vs. macro undo's we discussed at the gimpcon. Ctrl-Z could undo the last micro-operation: Toggling visibility, undo the last stroke... and ctrl-shift-z could undo all operations of the same type: Lets say we have the following operations on the stack: Stroke with Brush Stroke with Brush Bright/contrast Bright/contrast Bright/contrast Bright/contrast Bright/contrast Stroke with Brush Stroke with Eraser Stroke with Eraser Stroke with Eraser Ctrl-Z would work as usual, Shift-Ctrl-Z would undo the last three steps (all erasing) then the single brush-stroke (like ctrl-Z) and then all contrast-changes However, this is probably not possible for 1.2. I have no real clue of the undo system, but it may be possible that Brush and Eraser are currently undistinguishable for the Undo-system. To hack around this we could set some kind of flag to the current undo-step when the tool changes or the operation is fundamentally different from the previous. Ctrl-Shift-Z would then jump to the next undo-step with this flag set... Just my 0.02 DM. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
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
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 Wednesday, 7 Jun 2000, Sven Neumann wrote: > 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. Austin
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
On Tuesday, 6 Jun 2000, Raphael Quinet wrote: > I re-discovered an old problem with these scripts: some operations on > the layers are not recorded on the undo stack. If I am not mistaken, > these operations are: > - toggling the visibility of a layer, > - toggling its "preserve trans." flag, > - changing its opacity. And also changing the layer mode, if I remember correctly. I'm pretty sure I posted about this a while ago, but no-one seemed too concerned at the time, and I wasn't sure if these were operations people expected to be undoable. At the time I was concerned because changing these parameters changes the on-disk representation of the XCF file, but doesn't dirty the image. If you dirty the image, you must push an undo due to the way the dirty counter works (it counts the number of undo actions since the image was clean). So, the only was to set the dirty flag was to push an undo. But, I wasn't sure that these operations should be undoable. At the time, I don't think anyone had any views, so I dropped the issue. Now, you're telling me these actions should be undoable: great - that solves several problems :) 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? Austin
