Split SAXSGUIPlugin functionality into GUIPlugin mixins:
[ ] Calibrate
[ ] Mask
[ ] Reduce
[ ] Compare
[ ] Correlate
Shared functionality goes into a base mixin, SAXSGUIPluginBase.
Potential architecture blocks:
SAXSGUIPlugin depends on the use of xi-cam's TabView, which was written with a different architecture in mind (tracking field, stream, catalog model, selection model on the TabView, ...).
May need to implement "Active / Selected" ensemble in the DataSelectorView to make this easier to adapt to using the Intents and Canvases architecture. Limited to a single active ensemble in DSV.
For visual aspect, need a separate non qt active state for current items (add a role to Ensemble model, change font bold style or something).
Data flow through GUIPlugin?
EnsembleModel is a necessary visual component, but should not be something you always need to act with (should minimally act with it visually). Ideally, user wouldn't have to interact with it at all.
Enforce non-interaction with EnsembleModel (ie don't require checking new records every time)
Ensemble contains raw data and active derived data set. User doesn't need to see what is active. Whatever is active, everything is automatically checked. As new records are generated, they replace old active record.
Raw data set -> new Ensemble -> new active derived data set
Derived data set -> new Ensemble -> new active derived data set
active source record (input data) and and active destination record (record that would be overwritten if a new derived data set is produced)
default behavior of programmatic workflows: overwrite destination (default), also can append (via kwarg)
non-programmatic (workflow editor): default overwrite, give option to append (use a menu button, or checkbox)
overall, focus on user-story:
I want users to always create their workflows from scratch
Users should never need to interact with workflow creation; use a configuration / saved workflow
Plan:
Split SAXSGUIPlugin functionality into GUIPlugin mixins:
Shared functionality goes into a base mixin,
SAXSGUIPluginBase.Potential architecture blocks:
SAXSGUIPlugin depends on the use of xi-cam's
TabView, which was written with a different architecture in mind (tracking field, stream, catalog model, selection model on the TabView, ...).May need to implement "Active / Selected" ensemble in the DataSelectorView to make this easier to adapt to using the Intents and Canvases architecture. Limited to a single active ensemble in DSV.
For visual aspect, need a separate non qt active state for current items (add a role to Ensemble model, change font bold style or something).
Data flow through GUIPlugin?
EnsembleModel is a necessary visual component, but should not be something you always need to act with (should minimally act with it visually). Ideally, user wouldn't have to interact with it at all.
Enforce non-interaction with EnsembleModel (ie don't require checking new records every time)
Ensemble contains raw data and active derived data set. User doesn't need to see what is active. Whatever is active, everything is automatically checked. As new records are generated, they replace old active record.
Raw data set -> new Ensemble -> new active derived data set
Derived data set -> new Ensemble -> new active derived data set
active source record (input data) and and active destination record (record that would be overwritten if a new derived data set is produced)
default behavior of programmatic workflows: overwrite destination (default), also can append (via kwarg)
non-programmatic (workflow editor): default overwrite, give option to append (use a menu button, or checkbox)
overall, focus on user-story: