[Kst] Re: Default labels

[Barth Netterfield]

The intent was to just pass up the raw data to the plot, and let the
plot decide what to do, rather than passing the context down to the
primitive and having the primitive decide what to return.  It will be
messier in the plot code, but far easier to work on I think.

On Tue, Feb 15, 2011 at 5:49 PM, Peter Kümmel <syntheticpp at gmx.net> wrote:
> On 15.02.2011 21:49, Barth Netterfield wrote:
>> Here is what I am about to implement, unless there are objections:
>>
>> Introduce
>> struct labelInfo {
>>    QString Name;
>>    QString Units;
>>    QString Quantity;
>> }
>>
>
> First uppercase: LabelInfo ;)
>
> I would also introduce a getter functions with an argument
> which describes the purpose of the returned string, this makes
> it much more flexible and you don't have to touch much code
> when you wanna switch to a new or different behavior
> (or Nicolas doesn't like it ;) sorry couldn't resist.):

He is considering cases we don't have, which is pretty useful.

> struct LabelInfo {
>
>     enum Purpose {
>         MaximumDesciptive,
>         MinumumDescriptive,
>        CommonQuantity,     <- your case 1)
>         SameAbscissa,       <- your case 2)
>        ??????              <- your case 3)
>     };
>
>     QString description(Purpose p, const QList<LabelInfo>& otherLabels = QList<LabelInfo>());
>
>     QString Name;
>     QString Units;
>     QString Quantity;
> }
>
>
>> Relations (curves, images) get xLableInfo() and yLabelInfo()
>> Vectors labelInfo().  Matrixes get xLabelInfo and yLabelInfo()
>>
>> rather than QString xLabel, etc, as they do now.
>>
>> Then, the plotrenderitem and the legend boxes can make more intelligent choices.
>>
>> As to the more intelligent choices, there has been some discussion already.
>>
>> A couple points I'm not convinced about:
>>
>> 1) what should happen when Quantity or Units disagree when there are
>> more than one curve in a plot?
>>     A) don't list Quantity or Units at all in the axis label, and
>> instead put them in the legend with the name.
>>     B) List only one, since this should only happen if there is either
>> a typo or nonsense afoot.
>>     C) don't list Quantity or Units at all, since there may be either a
>> typo or nonsense afoot.
>> Right now it does B.  Nicolas wants A.
>>
>> 2) What should happen to the legend name when all of the curves have
>> the same named X vector?
>>    A) Stick with yName vs xName for all the entries, to keep things unambiguous.
>>    B) Just use yName, to keep things short, and change the X label to
>> xName: xQuantity [xUnits] (eg, CPU_TIME: Time [Seconds]), or xName
>> [xUnits] if quantity is not defined
>> Right now it uses A.  Nicolas has proposed B.
>>
>> 3) How should the user override the legend name if we go context
>> sensitive legend names (ie, 1A or 2B).
>> Right now, the legend name is the curve name, so you just change the
>> curve name in the curve dialog.
>>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>



-- 
C. Barth Netterfield
University of Toronto
416-845-0946