Alec Flett wrote:
So at the moment, I think one decision we need to make is when exactly an undoable action "ends" It sounds like there are a few possibilities: 1) open-ended: Transactions begin when particular CPIA events fire, and stay "open" until the next transaction starts. The advantage here is that UI changes get automatically bundled with their previous action, allowing the UI to return to exactly the previous state when the command ran. This is also the disadvantage, since many UI changes shouldn't be undone. 2) explicitly closed: transactions end either when someone calls EndTransaction(), or automatically with the CPIA events mechanism. The advantage is that undoable transactions aren't going to "leak" by staying open - i.e. an "open" transaction wouldn't start to accumulate irrelevant changes 3) Some hybrid, where CPIA events Begin transactions, and certain types of CPIA events could also "end" open transactions without starting a new one...
I think I'd go with possibility number 2: as expressed by others in this thread, there are too many scenarios that come to mind where an unbounded undo (possibility number 1) will backfire on the user.
Just to add one example not UI related: sending an e-mail or an invite for an event. Clearly, a repository based undo mechanism will be able to get the local repo to the pre send state but that's not a recall email mechanism, a subtlety surely missed by most users.
For some actions (like send invites or email), it's important to show users that those are *not* "undoable" (in a user centric sense) and make that very explicit. I think solution 2 gives us all the flexibility we need to make careful user centric choices on what's seen as undoable and what's not.
Cheers, - Philippe _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
