Plotting Refactor - Serialization and Undo Stack

[krzywon]

During our plotting refactor meeting, we started to discuss Serialization and an Undo Stack. The question was raised of how extensive would this need to be. This would track what was done, not only to the data, but also GUI interactions. Also, should existing project files continue to be supported?

Questions asked during the meeting:

• What should be tracked and what should be undo-able? Where do we draw the line?
• What should be serializable?
• Should old project files be supported in future versions?
• Could we have a file converter?
• What will the serialized files look like?
• Should the undo stack be the serialization method or an independent from this?
• Should the undo stack be persistent between project load states?
• File save format moving forward?
• Where should the save state live? Main sasview is suggested, but should it be sascalc or qtgui?

[lucas-wilkins]

There's also a question about how we make sure serialisation and deserialisation is correct. There's some obvious tests along the lines of serialising then deserialising and checking the state. A common problem with serialisation is that it often requires the programmer to remember to include and test every new field.

[lucas-wilkins]

Another question is how we make it robust to future changes. What if we add or remove a field between versions. Perhaps we could have some kind of decorator system that makes this easier to follow and check. Specify in the decorator what fields there should be, have "removed" fields which can be given code on a that will handle removed fields on a case by case basis. Or we have a decorator which allows you to specify what happens with different versions. Or something else.

[rozyczko]

What should be tracked and what should be undo-able? Where do we draw the line?

Surely we need any changes to (fitting and other perspectives) parameters to be remembered.
Currently, the trivial version of undo/redo is implemented for the fitting perspective, where upon any change to the parameters, the state of the fitting model is saved on an internal stack. This is wasteful and needs a serious redesign

What should be serializable?

We currently have a pretty decent (?) Project Save serialization. Undo/Redo can reuse this section to save certain aspects of the total state on a stack.

Should old project files be supported in future versions?

Probably not. We can offer a separate conversion tool for older projects/state saves.

What will the serialized files look like?

The current consensus seems to be JSON, but we might want to look at other formats. Qt internal serializer can be used with either JSON or XML (QDataStream)

Should the undo stack be the serialization method or an independent from this?

As mentioned, it would probably make sense to combine these two for the sake of maintainability.

Should the undo stack be persistent between project load states?

I strongly advise against that. The complexity seems significant and the applicability dubious (unless explicitly requested by users, I guess?)

Where should the save state live? Main sasview is suggested, but should it be sascalc or qtgui?

If we decide on using the Qt serializer, then obviously qtgui.

[lucas-wilkins]

What happens with the Qt serialiser if we start subclassing things?

[lucas-wilkins]

I guess we already do, but generally curious.