PRO_CHANGE_UNDO_MANAGER_R0

[Astea]

wiki page: PRO_CHANGE_UNDO_MANAGER_R0 - effort: 1d

[deyan]

Adding category

[deyan]

Correcting category

[gogov]

Ok, so some things are not right:

• In general, this task is tightly connected with PRO_CHANGE_MANAGER_R0 mostly, as well as other PRO_CHANGE tasks. You can read stuff in the analysis of these tasks to get a better idea about the whole picture or we can do a Skype session, if you want. So the the ChangeManager is more powerful than the UndoManager and is more an internal thing, opposed to the UndoManager which is more an external, end-user thing. So most likely the UndoManager will be a client of the ChangeManager and delegate user requests to it. This task is more about describing the end-user view of the UndoManager as he sees it while using Sophie 2.
• Stuff you've written about grouping and merging are kinda true but they are more like implementional stuff and are listed in detail in the respective PRO_CHANGE_* tasks, so these don't fall in this task.
• Stuff you've written about Auto, Group and ProChanges doesn't need to be included here. Also I think most of it's already implemented.
• When you read the analysis of the PRO_CHANGE_MANAGER task, you'll see what kind of functionality it provides. The goal of this task is to give an idea what should be available to the end user for control of undoing/redoing etc., and how it should be presented. See PRO_CHANGE_INFOS_R0 for further ideas.

[gogov]

• Also, currently the ChangeManager doesn't exist so the UndoManager is used to manage Changes, though it's not used correctly at all places. If you decide that there's enough effort for the task so some sort of refactoring messy client code which uses the UndoManager, you could include it in the task requirements.

[gogov]

Lots of stuff changed.. Will redo the analysis.

[deyan]

Batch update from file query-obsoleted.csv