<rjo>
imho a bargraph needs just one color. maybe two if there is a risk that the bars and the axes might blend visually.
<rjo>
sb0: i don't know where the grafana guys got the color map from maybe it came with flot. but the usual blue, green, red with black axes is not very smart since it already is a problem for ~10% of the typical users.
<rjo>
i was mostly ranting about shadows that skew the percieved bar heights, background gradients that among other things guide the eye to one edge of the graph (wrongly) etc.
<sb0>
alright, I made the bar blacks...
<rjo>
zyp: the thinking behind adding "beautiful" gimmicks to a graph is usually as shortsighted and misguided as the idea of adding beauty to text by using wordart.
<sb0>
since we're at it: I guess that for the XY plots, we'll want the original data and the fitted curve on the same graph. are black and red appropriate choices for respectively the original and the fit?
<rjo>
zyp: how do a background gradient or 3d effects help the presentation of numbers?
<rjo>
sb0: i have not looked at cairoplot. does it have the usual bells and whistles, like errorbars etc?
<sb0>
it has error bars, yes
<sb0>
also, it's fast (unlike matplotlib) and integrates well with python and gtk
<rjo>
sb0: my choice would be glyphs with errorbars for the data and a line for the fit. same color even.
<sb0>
where's the errorbar data coming from btw?
<rjo>
sb0: if it needs different colors, i think blue and black are pretty good. at least color blind people tend to be able to distinguish them. or black vs the dark green or brown-yellow that grafana has as the first few colors
<rjo>
depends. if you have the mean of a histogram, the stdev of that data is a good errorbar.
<sb0>
so all errorbars have the same size?
<rjo>
no
<rjo>
the histograms 0,10,0 and 5,0,5 have the same mean but different stdev.
<sb0>
sure
<sb0>
my question was: on a given plot, are all errorbars always the same size, or should we keep the possibility to set an errorbar size for each individual data point?
<sb0>
I was thinking of storing the plot parameters with each entry in the queue/schedule
<rjo>
sb0:
<rjo>
nah
<sb0>
since I guess you don't want to plot everytime, e.g. for the flopping-F, plotting should be done when checking if it works, but not when it's a calibration
<rjo>
"plot parameters" sounds very much data-structure
<sb0>
plot parameters = what datasets to plot, how, where to display
<rjo>
sb0: in that case i would want the plot but minimize the window.
<rjo>
as code or as data?
<sb0>
data
<rjo>
that won't work.
<rjo>
plotting is too flexible to fit into a datastructure.
<rjo>
it's not just {"x": "freq", "y": "photon_counts"}
<rjo>
afaict the plotting needs to be code (if desired with a useful shim layer between cairoplot/whatever and most commonly used plot functions).
<rjo>
there could be errorbars, asymetric errorbars, lines/dots/points/dashes, colors
<sb0>
"quick plot is only for making 1 simple XY plot and histograms, make it dead simple"
<rjo>
true. but since all other cases are require algorithmic plotting, a special datastructure for the simple plot is unnecessary.
<rjo>
s/are//
<sb0>
well in that case
<sb0>
for the difficult cases, the experiment can define functions that take a cairo context and handle the plotting. those would be extracted by the master and passed on to the GUI, which compiles and executes them
<sb0>
and you can do what you want with that context, not only use cairoplot but add arbitrary text or whatever graphical widgets
<rjo>
people will want multiple plot windows. isn't a cairo context within a window?
<sb0>
no, it's within a widget. and there's no problem having multiple ones
<sb0>
the custom plot function will just be called as many times as needed with different contexts, to draw every plotting widget
<rjo>
but yes. this is how i would implement it. for the "simple xy plot", that data processing/plotting method can just be inhereted.
<sb0>
is there a need to configure the plot from the GUI? like, fit type, plot type, etc.
<sb0>
or should all this be moved into the experiment file?
<rjo>
sb0: why can't the plot function just do everything? including making plot windows etc?
<sb0>
well, one experiment could define multiple plots, of course
<rjo>
sb0: yeah. a use case is running the experiment (lets take the flopping) and then playing with the data and the fit (changing/fixing parameters etc) without running it again.
<sb0>
why should the experiments touch gtk? for a plot, it's more like drawing on a sheet of paper, no?
<sb0>
why not put the fit parameters as regular experiment arguments?
<rjo>
they should not need to touch gtk (the ink and the wood). but they need to touch the plotting toolkit (the pencil color).
<sb0>
oh, that's cairo stuff
<sb0>
and yes that would be accessible
<sb0>
the experiments need to run the fit anyway, and sometimes use the result of it to update the parameter database
<rjo>
yes. that is how i would do it.
<rjo>
but digging out that parameter from the pdb needs to be easy.
<sb0>
what I'd do is: def run(fit_options): results = mess_with_hardware(); report(results); fit_params = fit(results, fit_options); report(fit_params); update_paramdb(fit_params["a"]);
<sb0>
then the plot would be configured to associate the proper dataset from the results with the fit parameters
<rjo>
almost. is the scan loop outside run()?
<sb0>
no
<rjo>
(i think this should be taken to the list and ting rei and justin should invest some time to think this through)
<sb0>
and the scan parameters would be run() arguments of course
<rjo>
but you want to report(results) etc on each iteration of the loop.
<sb0>
yes
<rjo>
and probably s/report/publish/
<sb0>
well, report would be broken down into create_dataset (as class attribute, like parameters and devices, so that the list of datasets can be known in advance) and add_to_dataset