[EMAIL PROTECTED] (2003-09-22 at 1959.36 +0200):
> So, if it's possible to have two different keybindings for the same command
> I'd like very much to have both.

You can always redefine commands, I will, I prefer the finger-dance
with two letters than with modifiers. Related to this, on IRC we have
been talking about undo ideas, for the future.

One was some kind of grouped undo (using Shift, that is the link to
this thread), but not clear how it should behave. When you are
painting, you can do lot of strokes, and undo one by one is tedious
and slow (so would be redo), suposing you do not waste all undo
steps. Thanks to the new system, consuming undo steps is no such big
issue like in previous Gimps (check the part about storing undo info
if memory is avaliable, in preferences).

But the workflow problem is still there. Undo history window can
help... sometimes. For example painting or drawing (hundreds of
strokes without changing tool) are not in those cases, cos the preview
is not enough for the task (the size of it vs the size of the real
change) and the description text saying the same always.

If all is undone as Sven proposes... I think you can change workflow
to use new layers or cloned layers, and forget about undo (discard
layer = undo). That plus Revert is what I have been doing in 1.2, to
cope with limited undo stack and single step undo (but not happy with

Thus the next idea is choosing how many normal steps should be a group
one, and if limiting it to "same kind" of step (IMHO, yes). I would
put it in preferences with the other undo things, to cover from "click
machine gun" to "all in one stroke" users. That or a spinner in undo
history window. The user defines what is his "unit" for an important
change, be it 5 or 50.

Side of effect of grouping, it could be used to compact really old
undo steps and save memory. Another idea floating around was time
stamps. It can be interesting in some cases too. But the one that
called my attention was grouping, due what I have been doing latelly.

Gimp-developer mailing list

Reply via email to