On Mon, 25 Aug 2008, Jerome Laheurte wrote: > But basically, being able to edit two objects at the same time (in two > different dialogs, that is) breaks horribly the undo/redo mechanism as > long as Command instances are used in the editor dialog... This will > be hard to work around.
Let me rephrase that: allowing anything in the main window while editing an object breaks undo/redo. Here is what I came up with so far. * So, top-level dialogs should not be modal. * "children" dialogs should be. * In order to avoid the command history mixup when the user works with 2 editor dialogs at once, the only sane thing I can think of is having a command history for each top-level dialog. Commands done in this context (and in children dialogs) are stored in the top-level dialog history. If the user clicks cancel, all commands in this history are undone; if he clicks OK, the history is converted to an AggregateCommand and appended to the global history. Let's call this the "what happens in Vegas stays in Vegas" strategy. * Users should not be able to delete/cut/etc an object being edited. This is simple; put a 'locked' attribute on domain.base.Object and use a NeedsUnlockedSelection mixin for 'critical' UICommands. * Objects may also be deleted by undoing their creation; so undo/redo should be disabled when editing an object. This covers most problems but not all of them. For instance, consider the following: create a category; create a task; in the task editor, edit the category, modify it, click OK (in the category editor). Now in the main window, delete the category (which isn't locked anymore). Click OK in the task editor. What happens is that now the global command history contains a command for the category deletion, and then an AggregateCommand that includes a command for the category editing. I'm pretty sure clicking 'undo' in this situation will raise an exception, trying to undo the edition of a non-existent category... Still thinking... Cheers Jérôme
