Strategy for Save Files - Future Proofing

[lucas-wilkins]

Problem Outline

We want to be able save the state of SasView, including the GUI state, and the state of the perspectives. This brushes up against the other desirable thing: being able to make changes.

Plan

Saved files should maintain a distinction between data that we don't mind loosing between versions, and data that should transcend versions.

Category I: Examples of data that we wouldn't mind loosing:

• Positions of windows
• GUI State in general

Category II: Examples of data where we need to still be able to read it:

• Data that we have open
• Plots
• Perspective parameters

For category I data, SasView can attempt to read, but if it fails, we ignore it.
For category II data, we should maintain backwards compatability.

Each section should be version controlled. If changes are made to things that use this data, and these changes affect the save data:

• A method to migrate old data should be written
• A repository of example files should be kept for testing migrations

The full save state should be separated into sections, which at the present moment, would align with the current multiplicity of save files. Each section should be versioned independently.

The full save state would look something like this:

• Save root (container)
  • GUI Data (Category I)
  • Perspective data (container)
    • Fitting (Category II)
    • Corfunc (Category II)
    • etc
  • File data (container)
    • SasData objects (Category II)
  • Plot data (container)
    • Plot positions, sizes etc (Category I)
    • Plot formatting (Category TBD)

Ambiguity

These categories are not forever, we might, for example, choose not to support some subset of the category 2 data if it becomes burdensome.

Status

Proposed

[lucas-wilkins]

see #3210