Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undo feature #51

Open
vincefn opened this issue Dec 30, 2020 · 0 comments
Open

Undo feature #51

vincefn opened this issue Dec 30, 2020 · 0 comments
Assignees

Comments

@vincefn
Copy link
Owner

vincefn commented Dec 30, 2020

Add an Undo feature in Fox GUI.

This could be implemented by saving regularly all objects in XML form and keeping them in memory.

This could exploit WXValidateAllUserInput() as a point where the XML configuration is systematically saved (if there was any change).

Notes:

  • undoing would close and re-open all windows
  • it should be possible to save/reload the XML specifically for some objects... But it would be necessary to keep track of the objects in memory with their different relationships. Tricky
  • need to take care of some sub-windows (indexing, profile fitting) which may be invalidated
  • some display options (Fourier maps, display ranges for the Crystal structures) would not be saved

Instead of saving a single XML file, it would be more flexible to save a list of XML for each top-level object, so that each one can be reloaded individually, after checking the changes with the current configuration.

When going back to a state with some deleted objects, the order to reload/delete objects must be checked. For example start from a state with a powder data and two phases cryst1 and cryst2, and go back to a state with only cryst1. The new cryst1 must first be reloaded (if there was any change), then the powder data, and only then cryst2 can be deleted. Generally the order to reload configuration should be Crystal, DiffractionDataSingleCrystal, PowderPattern, OptimizationObj, and the order to delete objects should be the inverse

Each 'saved' state could include 1) a timestamp and 2) a list of 4 list of objects' XML description:

  1. Crystal
  2. Single Crystal diffraction data
  3. Powder data
  4. Optimisation obj

For each type of object, keep a list of objects configuration as a pair <original pointer, XML string>, where the 'XML string' actually is a shared_ptr towards the real XML string. Using a shared_ptr allows to avoid copies of objects which are un-modified, e.g. when the Crystal structure is modified while the diffraction data is not.

@vincefn vincefn self-assigned this Dec 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant