[Kst] Re: branches/work/kst/portto4/kst

Peter Kümmel syntheticpp at gmx.net
Wed Feb 16 00:15:48 CET 2011


Does this problem have a general solution?

Isn't it better to change the code so that it can accepts parameters
which could be set by the user in a new configure dialog?

I assume, regardless of the oufcome of your discussion there
will be always a case which doesn't fit.

Peter


On 16.02.2011 00:05, Barth Netterfield wrote:
> On Tue, Feb 15, 2011 at 5:18 PM, Nicolas Brisset
> <nicolas.brisset at free.fr>  wrote:
>> Only shortly to the question regarding manual legends: if the name is not auto, I see no problem in taking the manually entered name for the legend entry. If the user wants a unit, then he can type it in.
>
> I am actually talking about the curve name in legends.  The curve name
> is "yvector vs xvector".  Which is necessary in a context free way,
> like in a list of curves.  But you might want to have the curve still
> called "yvector vs xvector" in the curve lists (because you also have
> a "yvector vs zvector" in a different plot) but in this particular
> legend, you want to call it something different, like "case 1:
> g=2200".  How should we do that in the UI?
>   i) a new text entry in the curve dialog "Legend entry name" with a
> "[x] Use Name" checkbox.
> ii) something else
>
>> I don't know what si still coming,
>
> A complete rewrite...
>
>> but at this stage I am not completely happy. Sorry to disappoint you,
>
> don't worry, you can't... I'm doing this for me :-)
>
>> but I liked it better before (only the top labels disturbed me), at least when there is only one curve per plot.
>>
>> To be a bit more specific (aka "constructive criticism"), here are some observations of a plot with the GOTEX[...].nc netCDF sample I like to use for test purposes, plotting 25 curves (5x5 grid):
>
> I assume, below that "label" means "Name".
>
>> - the X-axis label is along the x axis when I use time_offset (no unit) =>  OK
>> - the X-axis has no label but only the unit when I use seconds (unit: s) =>  BAD
>> - the Y-axis has only the unit, and the Y-axis label is displayed along the top X-axis =>  not very consistent, I much preferred the previous way with label + unit on the left
>
> Upon looking at it, I agree that this is sub-optimal.  The rule for 1
> curve, no quantity should be Name [Units].  We've never had this case,
> no top label.
>
>> - the top label of a plot is often closer to the unit of the above plot than to its plot =>  confusing, and there seems to be lots of free space between the top axis and the top label so we could/should improve that
>
> Yes.  There should be a margin setting.
>
>> - there is a lot of empty space between the units and the figures (see recent mail with a screenshot, nothing new here)
>
> This is a tricky one.  One of the plots had huge Y axis numbers, which
> pushes everything out.  I guess we could try moving the space to the
> left of the Y label.  Later.  Remind me once the other stuff is done
> (or put in a wishlist with "try" in the title)
>
>>
>> It's a bit late for me to think about all the options, but maybe some hints to possible improvements:
>> - display the units at the end of the axes (above the left axis for y unit, at the right end of the X axis for the x unit) - direction should be the same as label numbers in that case
>
> Not standard...
>
>> - always display the y label along the y axis and the x label along the x axis, or else in a legend (yeah, I know: I'm repeating myself here: for more than one curve, use only legends and not the top label!)
>
> Still thinking about it.  You might be right.  Once I've re-factored,
> it will be trivial to try different things.
>
>> Maybe I could also do some mockups. Should I?
>
> What we need is a matrix of cases with desired XLabel, YLabel,
> TopLabel, and Legend.  Can you make one (maybe a google doc or a
> document in DevelDocs. )
>
> By cases, I mean, what is defined, how many relations, what is the
> same, what is different, etc.  There are lots of cases.
>
> Name is always defined.  Quantity and Units are independently optional.
>


More information about the Kst mailing list