Future plot redesign

[lucas-wilkins]

These are my thoughts on the overall structural changes that would be needed for an sustainable approach to [improving] the plotting functionality.

I'm writing this with the idea want to be able to do the following things (I know there is always more things users want to, and that SasView currently does some of them, but I'm listing the things here which are design considerations):

• Have plots that update
• Have plots that are linked to each other, e.g. model, data, and residual, or SANS and SESANS
• Be able to move, duplicate, edit different plots without breaking everything above
• Be able to manage plots by having them grouped, pop in and out, etc

The following are the steps that I think should make that workable, which come down to a design rule:

• Data pushed from fits to plots, i.e. plots never request data, or reference mutable data

and an improvement the code

• A more detailed central location for tracking plot related objects

Detailed addressing system

The following is a strategy for maintaining as much flexibility in the plotting system, without it getting out of hand.

Instead of a single integer addressing each plot I recommend we introduce a semi-hierarchical reference system, which references from the level of single traces, to a collection of plots (currently we don't have this, but would like it).
This is to say, we should be able to reference elements of plots at a multitude of levels, and this should go down to level of individual traces within a figure, but access should not depend on providing a hierarchical address.

It would make sense to maintain a way of addressing the following from a central location:

• Lines - i.e. what is produced by plt.plot
• Axes - matplotlib axes objects (one for each subplot)
• Figures - each window
• Figure collections - future higher level of organisation

Lines shouldn't know what axes they belong to, axes shouldn't know plot they belong to, etc, etc. The same line could be in multiple axes/figure/collection and so forth.

Some examples, written here using a glob like syntax (this is just notation to articulate the structure, not )

a specific figure

collection1.figure7.axis2.line6

or all lines on an axis

collection1.figure7.axis2.*

all axes in a figure

collection1.figure7.*

or all lines in a figure

collection1.figure7.*.*

or all axes of a particular figure

*.figure7.*

a particular line, wherever it might be

*.*.*.line1

UIDs vs. semantic addressing

Each of the plot lines should be specified using a non-semantic UID. It should probably be possible to address axes and figures by specific properties, thus the naming should probably be semantic.

Referencing from other objects, copying, and linking

• Referencing - a fit, dataset, or whatever, can contain references to lines within plots, e.g. *.*.*.line1
• Copying/Duplication - This should happen at the model level (in the model-view-controller) sense, plots shouldn't reference each other directly. Want two plots for a fit, the fit object should know this, not the plot (this will help a lot with serialisation, and clean data flow). The alternative would be "cloning", where a clone object has derived fields until it is set, but this will break the push-data approach.
• Linking - plots that go with other plots should be linked at the model level

Avoid back referencing from plots

When data flows in two directions things get messy, so I suggest the following

1. Data should be pushed from the models and calculations to the plots
2. Plots should not contain references to mutable variables.

This also solves some potential issues with serialisation

Serialisation

• Whatever form of plot reference is used, it needs to be serialisable, and compatible with saving and loading procedures - this favours a UID type approach
• If plots don't contain references to mutable variables, their contents can be serialised and saved without worrying about how the plot is linked to other things.

Data-Push Approach - An exception that proves the rule

One example that might seem to necessitate breaking the data-push rule is interactive plots is user feedback from plots.

In this case, either:

• Classes that need data from a plot, say the positions of lines, should request it when it is needed, or, if that does not suffice
• Plots should broadcast an event globally
  Neither of these break the data-push rule, but will allow for the desired functionality

Let me know what you think,

@gonzalezma @rozyczko @krzywon