[Kst] Re: On the way to 2.0.3
nicolas.brisset at free.fr
Sun Feb 6 22:50:02 CET 2011
So, here are some answers and use cases... I think there are only some details that are wrong, but it needs a bit more test and discussion.
The tests are done with the GROUNDTEST+fixed-width+delimiter+windowsEOL+comma-decimal-separator.txt file in sample_data/ in the svn source tree.
> - use the left + bottom labels if it's only one or two curves in the plot
> That is what it should be doing now.
Yes, more or less. If you load e.g. p, q, r (using units) into one plot from the wizard, you get:
- 3 curves in one plot => OK
- no top label => OK
- a legend => OK
- a left label with only "q [deg/sec]" => WRONG, in that case it should either contain the 3 vectors, or be removed
Note: 2 or 3 curves exhibit the same behavior.
- if there are more curves, then switch on the legend and probably remove the left label (as it mostly can't contain all the names anyway)
> 'Auto-legend' in the data wizard does this.
Right, exactly. The auto-legend option is nice. The question is, shouldn't it also work outside of the wizard, i.e. when you add a curve to a plot later from the "Edit Plot" dialog? If you load the 3 vectors each in a plot, and then add the two others to one of the plots, it does not switch on the legend - but the top label is correctly updated. Maybe we need a concept of auto-top label vs auto-legend, and make that property part of the plot so that it's preserved for its lifetime (unless explicitly changed by the user).
> So, the top label is only there when it is useful and non-repetitive.
Do the following experiment:
- load p, q, r each in a plot: you get top labels which say even less than the left labels => definitely superfluous
> So, yes, if you can send me some png's of kst not doing the right thing (and specifics, like field names and units/quantities, etc), that would be useful.
I hope the above examples help you understand my issues. I wasn't aware just how clever the whole thing is. I'd bet you don't work with ASCII all that much, because the quantity stuff seems to be a fairly advanced concept, but for simpler use cases (ASCII) it leads to sub-optimal behavior.
As I'm still a bit confused about your use-case and intent, I can't really suggest the unified approach that will fit all, but I'm pretty sure we'll find the right way. We're certainly pretty close, let's get this straight and make a very nice release!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kst