[OT] App. design: Should *selection* be part of undo/redo history?

[Milan Babuskov]

Paul Koning wrote:
> Most apps say "no" but some major ones say "yes".  One that says "yes"
> is Adobe Photoshop.

Same story with Gimp.

> I'd look at it this way: "undo" should be available on an operation
> that is (1) changing the state of your data, or (2) hard to repeat.
> 
> Clearly (1) doesn't apply to selection.  (2) doesn't apply for most
> apps; for example, in a text editor, selection is easy.  On the other
> hand, if selection could be a complex multi-step process, then it
> belongs in the history.  That's the argument in Photoshop: it's easy
> there to spend quite a while selecting just the right thing by "add to
> selection" and "subtract from selection" etc., and having all that
> work evaporate without recourse would be annoying.

Also if you have a selection that took 5 minutes to create, and start 
adding/subtracting to it, undo/redo works on parts as well. Each small 
step (change in selection) is a different item in undo history. I'm not 
sure if this is the way it should be done in text editor as it would 
mean that each single-character change should be a separate item in history.

Maybe you should only implement selection in history when some action 
causes selection to be lost. For example: cut, replace and similar 
actions might destroy the current selection, so undo would revert it.

-- 
Milan Babuskov
http://www.flamerobin.org