[Kst] Re: On the way to 2.0.3

[Nicolas Brisset]

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! 

Cheers, 

Nicolas 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kst/attachments/20110206/48a29b70/attachment.htm