Manual save system and undo/redo

[svetter]

Only save changes to base table buffers, and keep score of which changes were made. Allow the user to step through that list of changes with undo/redo operations. On save, go through list of changes and commit to SQL.

Both the buffers and SQL module will have a pointer to the list of changes which can be moved by undo/redo (buffers) or saving (SQL), respectively.

Backend

• Create container classes for the different kinds of changes
  • Base class
  • Add row
  • Update row
  • Delete row
• Create tree of change objects
  • Root is project open (no undo possible)
  • Pointer for runtime
  • Pointer for persistent storage
  • Pointer for last node seen before undo chain
• Create class TempItemID or other solution to ID problem
  • Make sure it is compatible with the tree format
• Create system for assigning (translated) names to change objects

Event handling

• On user change
  • Create new change object
    • If user change will remove data, save it to the change object before actually removing it
  • If current node in the change tree is not a leaf, check whether any child node is identical to the new change object
    • If so, move the runtime pointer to that node
    • If current node is a leaf, add the new change object as a new leaf and move the runtime and redo pointers
  • Make changes in cache
  • Prune any subtree of the previous runtime pointer node which does not contain the runtime or storage pointer
• On save
  • Determine path between storage pointer and runtime pointer (least common ancestor)
  • Walk along path and execute changes on SQL
  • Prune change tree
    • Remove any node which is neither ascendant nor descendant of the current one
• On undo
  • Execute changes of current change node on caches (backwards)
  • Move runtime pointer to direct parent
• On redo
  • Move runtime pointer to direct child
    • If there is more than one child, choose the one which is an ancestor of the redo pointer
  • Execute changes of current change node on caches (forwards)

Frontend

• Create menu bar entries for undo and redo
• Create sub-menus for multi-undo and multi-redo
  • List of n previous/next changes
  • On click, move to clicked state
• Create keyboard shortcuts
• Show confirmation message in status bar after undo and redo

Finalization

• Test and debug
• Make sure default hiker setting works correctly or at least safely

[svetter]

ID problem

New items get their IDs from the data base. If they're not saved to the DB straight away, they don't have IDs, which are needed immediately.

Possible solution: New class like TempItemID : protected ValidItemID, used for new items in place of ItemID/ValidItemID. While committing the changes from list to database, a map from TempItemIDs to new database keys is kept and TempItemIDs replaced. TempItemIDs can be assigned starting just above the highest ValidItemID of its item type, because the only way new actual ItemIDs can be created is by the database, which is a controllable process.

[svetter]

Optional advanced feature for the future:

Tree undo/redo

• Remove any tree pruning
• At change nodes with multiple children, allow user to select between them
• Critically requires good naming system for change nodes