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
• 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
  • Make changes in cache
  • Create new change object
  • If the previous node in the change tree has another child, remove that subtree unless it contains the storage pointer
• On save
  • Determine path between storage pointer and runtime pointer
  • 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 does not 'contain' the storage 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

[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:

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