[Kst] [Bug 117817] Only the first parameter is shown in fit labels
netterfield at physics.utoronto.ca
Tue Feb 28 23:45:01 CET 2006
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
> 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
> 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.
More information about the Kst