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

[Carsten Fuchs]

Dear folks,

first of all, sorry for this off-topic post, but as I think that this is still the right and very 
competent audience for this, I'll ask the question here:

The key question is: How should the object selection behave, and should the object selection state 
be part of the undo/redo history?

We're working on an application where you can create, modify and delete 3D objects. Objects can be 
be selected with the mouse. Most commands that the user can activate operate on the set of currently 
selected objects. The "Command Pattern" as described in the book by Gamma etc. all ("GoF") is 
employed to manage the commands and to implement a undo/redo history.

The same principles apply with many other applications, e.g. a text processor where you select 
portions of text with the mouse and there are commands to make the selected text bold, cursive, 
underlined, etc.

One key issue is if the selection should be "volatile", i.e. generally and unconditionally vanish 
after the execution of each command (this is the most simple case), if it should "sometimes" vanish 
(e.g. when it is too inconvenient to keep it), or if changes to it should even be part of the 
undo/redo history, as e.g. in Gimp.

In this context, I was wondering how applications should deal with the interference of the selection 
state of objects with the undo/redo system. Consider this example:

1) Text processor: The user selects a portion of the text, then activates a command that e.g. 
replaces the selected text with 10 repetitions of that text. The command also updates the 
selection(!) to cover the entire new text, i.e. all 10 repetitions. Now the users does "Undo", then 
selects a different text. Now he does "Redo".
Obviously, the same text is changed as before (independent of the current selection being elsewhere 
now), but how is the current selection supposed to behave? Stay as it was last before the "Redo" was 
run, or update to be the same as it was after the original command (the first "Do")??
(What if the last selection partially contained the text that the Redo affects?)

2) 3D app: The user creates a single step of a stair, then activates a command that automatically 
creates a spiral staircase from that step by duplicating it many times and moving/rotating the 
copies appropriately. The command also changes the set of selected objects to contain all the newly 
created steps of the staircase.
Now the user clicks onto an entirely unrelated, different object, say the floor, and thus changes 
the selection again (the floor is the only selected object now).
Then he does "Undo" (remove all new steps, restore the single starting step). Should the Undo 
implementation restore the selection as of that step as well, or should it not touch the selection 
and keep the floor selected?
Now the user does "Redo", and the same question occurs again: Should the system update the selection 
to the state it was after the original command (entire staircase selected), or should it leave the 
selection alone?
Note that if this was not the "Redo", but the original first "Do" run, it should update the 
selection as described above.

The best I've found so far is 
http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Concepts/Undo.html but it 
doesn't really address these issues either.


Well, in summary, I find some problems to understand the concept of selection wrt. application 
design clearly. Is this a known problem that has known solutions? Exist any guidelines, paper, books 
etc. in this regard?
How do you solve such problems in your apps?

I'd be very grateful for any hints, tips, tricks, links, etc.

Thank you very much in advance,
and best regards,
Carsten



-- 
Ca3D - Engine    http://www.Ca3D-Engine.de
Carsten Fuchs    http://www.Ca3D-Engine.de/c_Carsten.php