[Kst] Re: On the way to 2.0.3

[Nicolas Brisset]

Hi Barth, 

thanks for your answer. I have the feeling that we are quite close. There are only a few points where I don't completely agree: 

> I think it is fine to assume that an axis has only one quantity [units] even if there are multiple curves in the plot. 
> [...] 

> Units don't ever belong in auto-legend names. They belong on the axis. 
I am not sure. Imagine you want to check that a speed in knots and one in m/s have the same dynamics, there is only a factor two and plotting them on the same plot is the best way to compare the shape of the curves. We do that quite often... So I think this assumption is dangerous. As showing wrong units is very bad/confusing, I fear we can't get around taking that into account. 

> I think that the Name should appear either in the top label or the legend, at the user's choice, and not in the axis label, 
> unless there is only one curve int he plot, and quantity/units are not defined. 
If there is only one curve and quantity/units *are* defined, I'd prefer to have per default "quantity: name [unit]" in the left label and use the space of the top label for the curve itself. 
I suppose your point is that the string can become too long, which it may indeed, especially if quantity is defined. Now the thing is, in my use cases it never is. In yours probably always... I'd almost suggest making the "quantity:" prefix an option in the settings, as most people should know it from the unit anyway. I for one think I'd rather turn it off. And it'd give more chances to have short strings. Then the other thing we could do is check the length of the string, and if it's too long then automatically switch to having the name in the top label and only quantity/units in the left label. 
It sounds like quite some effort, but really, in 90% of the cases we just plot a bunch of curves one per plot and it looks better to have names in the left label, as is the case now. 




> Plot auto can be bad for real time data - legend bouncing around! 



Yes, you're right. I mentioned it just because it came to my mind as I was thinking about the whole legend/label stuff. But it's not high on the priority list, and possibly difficult to implement or time-consuming. If we have legends above the plots ("super top-labels"), we probably don't really need this. 

> But I like the 'super top-label' idea. 
Yes, I think this is really useful. Especially as a top label without legend does not help: you can't identify the curves! And having names in both the legend and the top label sounds like a waste of space. If it's too much for 2.0.3, we can at least try to have nice legends automatically at the right time, and in the next step we'll offer the option of drawing them above the plot. 


> Right now this (legend auto/always/never) is not a property of the plot, but is rather a datawizard option at creation time. 
That's what I thought. I think at some point we should change it. The datawizard would just set/unset the property with the corresponding setter function. 

> This is what I have just re-implemented. 
Maybe you could commit your changes, and we do incremental changes until we've reached a good compromise, possibly with a TODO list for the next release. As long as we have clear changes in mind, I think it's OK. 
Such e-mail threads are a bit hard to follow, as soon as the concepts are clear some hands-on testing is probably the best way to converge. 

To conclude, the summary of what I understand still needs to be done in a first step: 
- legends laid out horizontally by default 
- quantity optional so that name [unit] can be used in the left label when there is only one curve per plot 
- switch on/off legends automatically according to the number of curves > 1 or <= 1 
- plan the case where the units have to be in the legend and not on the axes (different units in different curves in the same plot) 
- allow legends above the plot ("super top-label ") - this one maybe for 2.0.4 

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