From kde-bugs-dist  Tue Feb 28 22:54:14 2006
From: George Staikos <staikos () kde ! org>
Date: Tue, 28 Feb 2006 22:54:14 +0000
To: kde-bugs-dist
Subject: [Bug 117817] Only the first parameter is shown in fit labels
Message-Id: <20060228225414.22735.qmail () ktown ! kde ! org>
X-MARC-Message: https://marc.info/?l=kde-bugs-dist&m=114123791224235

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=117817         




------- Additional Comments From staikos kde org  2006-02-28 23:54 -------
On Tuesday 28 February 2006 17:45, Barth Netterfield wrote:

> 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...


  I was thinking exactly that as well.  RVectors wouldn't get it though, since 
they're primitive objects.  They'll be detected as vectors and their data 
dumped.

> > 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


   That's certainly easiest to render.  Is it really what users will expect?  
I can think of many different looks.  One might be to follow the vertical 
justification parameters.

> > 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].


  There is that as well.

> -Just give one precedence
> -dataobjects share a namespace with scalars
> -We use a special character for object labels eg [$myfitlabel]
>
> I like #3.


   Right now primitives have precedence.  If we use a special character, we 
have to ban it in tagnames, which could break some kst files.

   #2 could also break existing kst files.