I think there is another problem: the dots ('.') seem to be escaped, so that if you fit 1.23*x + 4.5 you will get a fit label saying "123*x + 45". I actually think I have seen this problem in other labels too, but I can't remember where right now.

For the comment from Nicolas:
This is because the dots ('.') get dropped from the curve name created from the equation, not because they get dropped from the fit label. If you think this is a problem then please enter a new bug report.

For the original bug report:
When the label is created the output vector containing the fit parameters has not yet been updated, and has its default size of 1. As a result only the first parameter is displayed - which gets updated on the display as soon as the fit has been updated for the first time. The solution would be to update the entire label at this time, but the label is an independent object at that point.

Any ideas on how to fix this?

The proposed solution here would be to introduce some new syntax such that a label could indicate it would contain the results of a particular fit. At the simplest this would be [<fit name>], using the same syntax as for scalars. If no scalar of such a name existed then the existing fits would be searched.

I like the suggested solution, but I worry about namespace collision.
We are essentially introducing the syntax which will eventually be used for all 'string' references...  
options: 
1) strings and scalars share a name space, so if there is a string called [abc], the scalars named [abc] are forbidden.
2) strings and scalars don't share, and so need to be reference strings in a different way than we reference scalars.  so [abc] vs , eg, [$abc]

I prefer (1), but it will be very hard to enforce, I fear.  (2) will be a lot easier implement.

Thoughts?

I think 1) or 2) are acceptable. It will mostly be a matter of documenting it properly and getting used to it... I'd say we can go for the cleanest and/or easiest implementation.
However, I have a concern regarding the sequence of events. From what I have understood, text labels from fits need to be updated when the fit plugin returns, which happens *after* they are created. But I thought that labels don't update automatically at the moment (even though that'd be very cool, as discussed in a few occasions, e.g. plot titles with datasource names or plot contents changing and axis labels not being updated). What's the actual status wrt automatic label update ?

On Wednesday 22 February 2006 02:00, netterfield@astro.utoronto.ca wrote:

> 08:00 ------- I like the suggested solution, but I worry about namespace
> collision. We are essentially introducing the syntax which will eventually
> be used for all 'string' references... options:
> 1) strings and scalars share a name space, so if there is a string called
> [abc], the scalars named [abc] are forbidden. 2) strings and scalars don't
> share, and so need to be reference strings in a different way than we
> reference scalars.  so [abc] vs , eg, [$abc]
>
> I prefer (1), but it will be very hard to enforce, I fear.  (2) will be a
> lot easier implement.


   Strings and scalars presently share a namespace.  Strings are considered 
scalars of letters instead of numbers.  I'm really afraid of allowing too 
much namespace overlap though.  We're much safer using only a couple of 
namespaces so that we avoid ambiguities, especially in equation and label 
parsing.

So, we should use [abc] to refer to strings.

In that case, the auto label string produced by a plugin "abc" will be [abc], 
as suggested by Andrew.  Or is there another suggestion?

On February 23, 2006 06:09 am, George Staikos wrote:
>    Strings and scalars presently share a namespace.  Strings are considered
> scalars of letters instead of numbers.  I'm really afraid of allowing too
> much namespace overlap though.  We're much safer using only a couple of
> namespaces so that we avoid ambiguities, especially in equation and label
> parsing.

On Thursday 23 February 2006 09:15, netterfield@astro.utoronto.ca wrote:
> 15:15 ------- So, we should use [abc] to refer to strings.
>
> In that case, the auto label string produced by a plugin "abc" will be
> [abc], as suggested by Andrew.  Or is there another suggestion?


  I think that makes sense.  What happens if there is already a string with 
that name?  It's up to the plugin to generate the name anyway...

... and the plugin can't know what strings are already "taken" !

On Thursday 23 February 2006 09:56, Nicolas Brisset wrote:
> 15:56 ------- ... and the plugin can't know what strings are already
> "taken" !


  No, it would be done on the Kst side of the plugin, so it can do a lookup 
easily enough.  It may result in some strange string names, that's all.

Created attachment 14909 [details]
Proposed patch

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.  There's another 
issue I see.  What do we do if we have this label?

"Text [myfitlabel] more text"

If I'm not mistaken, it will render "Text" at the top, and "more text" at the 
bottom.  We should define the semantics for inline text blocks that span 
multiple lines first, or we should only accept fitlabels that are exactly 
"[fitlabel]".

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.

Created attachment 14919 [details]
Proposed patch

I think this addresses the major concerns, given the conflicting opinions. 

I have not added the virtual label() method as it is not really a necessity for
this bug. If this is something that should be done for other reasons then
another bug report should be entered.

On Wednesday 01 March 2006 14:07, Andrew Walker wrote:
> I think this addresses the major concerns, given the conflicting opinions.


   We still need to define what the behavior is for text blocks.  Also there 
is some odd whitespace changing in the parser which should not go in, lots of 
random whitespace addition, unneeded #includes in the renderer, and the 
renderer should use a const QStringList with a const iterator for performance 
reasons.  Also I guess it would be a good idea to make strList and txtAll 
const and initialized directly.  Any slowness in labels has proven to be very 
user-visible.  QMAX should be replaced with kMax for type safety (I fixed the 
other places where it was used).

  Those small things should be very quick and easy to fix, and once we have a 
defined behavior for text blocks, as long as this follows it, it looks good 
to me.

SVN commit 514942 by arwalker:

BUG:117817 Render text blocks as per Barth's suggestion. Fix indentation in labelparser.cpp

 M  +1 -1      libkstapp/dataref.h  
 M  +9 -26     libkstapp/kstfitdialog_i.cpp  
 M  +19 -0     libkstapp/kstviewlabel.cpp  
 M  +41 -1     libkstapp/labelrenderer.cpp  
 M  +24 -0     libkstmath/kstplugin.cpp  
 M  +2 -1      libkstmath/kstplugin.h  
 M  +4 -4      libkstmath/labelparser.cpp  

  So the plan is to just change this again if we decide on rendering blocks 
differently?  I have no plans to make strings render this way until we have a 
solid reasoning and plan behind it.

Yes. Okay.

-----Original Message-----
From: George Staikos [mailto:staikos@kde.org]
Sent: Wednesday, March 01, 2006 4:23 PM
To: kst@kde.org
Subject: [Kst] [Bug 117817] Only the first parameter is shown in fit
labels


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=117817




------- Additional Comments From staikos kde org  2006-03-02 01:22 -------
  So the plan is to just change this again if we decide on rendering blocks
differently?  I have no plans to make strings render this way until we have
a
solid reasoning and plan behind it.
_______________________________________________
Kst mailing list
Kst@kde.org
https://mail.kde.org/mailman/listinfo/kst