Re: The undo stack does not record some changes in layer attributes

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

 



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






[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