Changes between Version 12 and Version 13 of PRO_CHANGE_MANAGER_R0
- Timestamp:
- 01/23/09 18:40:34 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PRO_CHANGE_MANAGER_R0
v12 v13 6 6 7 7 == Overview == 8 This task is related to the !UndoManager. The change manager is like the undo-manager, but allows skipping, unskipping etc. Currently we have an !UndoManger which will later become a change manager with the additional features described bellow. 8 The Change Manager is meant to be a general manager for changes which supports a list of (mostly) all actions done in Sophie 2, implemented as changes. [[BR]] 9 It's meant to provide undo and redo functionality to the application, as well as help implementing online collaboration. 9 10 10 skip change, unskip change, undo change, 11 * The Change Manager is meant to consist of a list of changes, and each of them should have a unique '''id''' (most likely a number) 12 * The '''id'''s of the changes need to be in increasing though not mandatory consecutive order 13 * Each of these changes should be able to handle 4 commands applied to them: 14 * undo 15 * redo 16 * skip 17 * unskip 18 19 Right now only the UndoManager exists but later it could evolve to ChangeManager (or less possibly exist as a separate entity). 11 20 12 21 == Task requirements == … … 17 26 * undo/redo - the undo/redo mechanism should behave in a generally accepted manner as in most applications nowadays. 18 27 * '''Important:''' 19 * skip/unskip and undo/redo are all going to be defined as changes. This way undoing a change can be skipped and later unskipped. Skipping a change can be undo. If one is unskipping the skip of the last change, that should act as if he/she is undoing the last change. 28 * skip/unskip and undo/redo are all going to be defined as changes. This way undoing a change can be skipped and later unskipped. Skipping a change can be undo. If one is unskipping the skip of the last change, that should act as 29 if he/she is undoing the last change. 20 30 * undo/redo should be possible to be skipped and unskipped. 21 31 * skip/unskip should be possible to be undone and redone. … … 23 33 24 34 == Task result == 25 * review of current source code .26 * more source code .35 * review of current source code 36 * more source code 27 37 * unit tests 28 38 29 39 == Implementation idea == 30 * review current code. 31 * add the new features. 32 * write unit tests. 33 '''Example scenarios - every number represents a change and its position in the list:''' 40 * review current code 41 * add the new features 42 * write unit tests 43 44 === Example scenarios === 45 * each command will have a number as an id 46 * these numbers should be in increasing order, though it's not mandatory for them to be consecutive. Every number represents a change and its position in the list: 47 * each '''''skip''''' and '''''unskip''''' command has a single number as argument which is the id of the command it's meant to affect 48 34 49 {{{ 35 50 skip: … … 68 83 }}} 69 84 70 '''Notes:''' 71 * skipping the previous change acts like a undo. 72 * unskipping the previous change acts like a redo. 85 === Notes === 86 * skipping the previous change acts like a undo 87 * unskipping the previous change acts like a redo 88 * in some cases some unskips act as opposite to certain skips, so they could be ruled out to increase performance but right now it's quite hard to deal with such cases, so this could possibly be reconsidered in a further revision of this task 73 89 * there may be more interesting facts that can be observed. Design should take care of these... 74 90 * Be careful to consider the !UnmanagedChange type - a change that is supposed to be managed in a special way. Its undo and redo will be implemented as the situation requires. For example - save a book may be a unmanaged change. If the user creates a frame with a movie content (with a media file of over 700Mb), deletes the frame, deletes the media file and requests a undo - the change may become a unmanaged. If the user had not deleted the media file the change would have been a normal change that can be undone. 91 * one can argue if actually all the four operations are needed internally but at least to the end user they should be available 75 92 76 93 == Related == … … 82 99 83 100 == How to demo == 84 101 * Show the skeleton code of the ChangeManager which is implemented 102 * Run the corresponding unit tests 85 103 = Design = 86 104
