Draft: Flint: plotselect
Here is a draft to implement back features around plotselect
and Flint.
plotselect
was used in the old time of Spec to interact with the plot and other stuffs like that.
The Spec plot was not interactive: the user was not able to interact with the plot window with the mouse, but could use the Spec console to request things. With Flint the approach is not the same. The plot is interactive, and inconsistencies have to be taken into account.
Basically it would be good to:
- Provide an understandable context for the user
- Have a clear requests from the user
- Avoid synchronization problem
Working on plotselect
must then taking care of all the ways to interact to Flint.
Use cases
Use case | Previous way | Proposal | |
---|---|---|---|
1 | As a way to select the default plot for the new scan |
plotselect(diode) ascan(roby, 0, 1, 10, 0.1, diode, diode2) |
This must be avoided. For that, many things could be done, but mostly a new entry for
s = Scan(...) s.scan_info["flint:plots"] = { ...to be defined... } s = Scan(...) # which will basically feed the scan_info s.add_default_plot( ...to be defined... ) # which will basically feed the next scan_info default_plot( ...to be defined... ) ascan(...) |
2 | To interact with the current plot |
plotselect(diode) |
This is fine, it was designed for. |
3 |
To custom |
plotselect(diode) cen(roby) |
Prefer this way:
cen(roby, diode) Using It is definitely not safe for scripting. |
4 |
To custom |
This still can work |
Proposal
- Ensure that
plotselect
can be used only for live plot interaction (else that's the user responsibility anyway) - Update the measurement group shell GUI to allow to display or not things
- Provide a
scan_info
language to allow to define default plot to display (for custom scans)- It's the responsibility of the acquisition chain designers to take care of (2)
- Update common scans (
ascan
,dscan
...) to provide (3) from info of (2)
scan_info language
This have to be defined to provide default plot in Flint which can be custom.
It is obviously not designed to be used by users.
It provides
- A clear request of what to do
- A perfect synchronization between the scan acquisition and the rendering requested
But as it is planed, it can be defined later on. And improved.
Plus, I am pretty sure there is overlap with the work of the HDF5 writer, but this can be clarified later.
Here some ideas.
- Care about curves and scatters
- Images and MCAs don't need that right now
- Use a plot based description language
- Feed the
scan_info
with an entry dedicated to that use case
Example:
scan_info["flint:plots"] = [
"default_plot": {
"kind": "curve",
"items": [
{"x": "axis:roby", "y1": "diode:diode"},
{"x": "axis:roby", "y1": "roi5:avg"},
{"x": "axis:roby", "y2": "diode:diode2"},
]
}
"default_plot2": {
"kind": "scatter",
"items": [
{"x": "axis:roby", "y": "axis:robz", "value": "diode:diode"},
]
}
]
That's ugly but complete. It will be designed to fit plot modelization used in FLint (at first the main useful subset).
It can be achieved with few helper functions.
scan = ascan(...)
scan.flint_plot().add_curve("default_plot", x="axis:roby", y1="diode:diode")
scan.flint_plot().add_curve("default_plot", x="axis:roby", y2="roi5:avg")
scan.flint_plot().add_curve("default_plot", x="axis:roby", y2="diode:diode2")
scan.flint_plot().add_scatter("default_plot2", x="axis:roby", y="axis:robz", value="diode:diode")