[Kst] [Bug 117817] Only the first parameter is shown in fit labels

[Barth Netterfield]

On February 28, 2006 05:23 pm, George Staikos wrote:
> ------- Additional Comments From staikos kde org  2006-02-28 23:23 -------
> The construction of the label should go into the Fit class.  We don't want
> to lose sync between the two locations where it's constructed, and neither
> of those locations should really need to know about it anyway.  

so the fit has a method that returns a QString?  I think that makes sense.

It might even make more sense to have this be a virtual method of dataobjects 
in general, so all data objects (plugins, curves, vectors...) can, if they 
want to, return a label.   The default return string could be the tagname, 
but, eg, eventually (and easily) RVectors could produce "FIELD, FILENAME, F0, 
N" formatted somehow, curves already have the "legend label" which this could 
absorb, etc...

> There's another issue I see.  What do we do if we have this label?
>
> "Text [myfitlabel] more text"

Imagine that we are getting the fit label for a n=3 polynomial:

In my optinion, the above example should expand to:
 "Text x0 = 1.0\nx1 = 2.0\nx3 = 3.0 more text" 
which would render as

Text x0 = 1.0
x1 = 2.0
x3 = 3.0 more text

> If I'm not mistaken, it will render "Text" at the top, and "more text" at
> the bottom.  

I think that would cause consistency problems.  I prefer the above 
interpretation.

> We should define the semantics for inline text blocks that 
> span multiple lines first, 

I vote for the interpretation I just gave

> or we should only accept fitlabels that are 
> exactly "[fitlabel]".

???

I am more concerned about the question of what we do if there is both a scalar 
called [myfitlable] and a fit plugin (or, with the above suggesion, a any 
data object) called [myfitlabel].

-Just give one precedence
-dataobjects share a namespace with scalars
-We use a special character for object labels eg [$myfitlabel]

I like #3.