[Kst] [Bug 128483] UI: the "quick curve creation" part of theequation dialog should be clearly separated

[Barth Netterfield]

Now that I have slept on it...

If we had the opportunity to do it over, we could possibly ditch the concept 
(2) of x in equations all together because of this confusion.  But we are at 
1.3, and making a change that will effect people's kst files is not really an 
option.

We also could attempt a work around: the equation xml parser could pre-parse 
equations and replace x with [approprate_vector].  

The other possibility is that the equation could export its X vector as a 
slave vector, which curves can use (esp the autogenerated curves from the 
equation dialog), so that X concepts 1 and 2 could be locked (ie, it would do 
what the UI currently suggests it will do).   Of course if someone edited the 
curve by hand and selected a different vector for X, the equation wouldn't 
know about it and the relationship would be broken, but it would have been 
broken by hand.

This is what PSDs do, and it has worked very well.  I actually like this 
second option a lot better than the first.

thoughts?
cbn

On Thursday 08 June 2006 01:26, Brisset, Nicolas wrote:
> > The problem is that the 'x' vector serves two purposes:
> >
> >   1) the X vector in the auto-created curve
> >   2) the vector that replaces 'x' in equations (eg, when you
> > enter x^2)
>
> I don't get this... For me, the "X vector" combobox was used to indicate
> which X vector to use in the auto-created curve and that's all. If I
> want to plot x^2 with x being, say, Vec1, then I'd simply write in the
> equation lineedit: "[Vec1]^2". I don't  understand why we'd need
> something like an auto-interpret x as ..., especially when there is only
> one dialog item to select it. Sure, it is somewhat shorter to write but
> not worth the confusion it creates as far as I'm concerned.
> The only case where I imagine where this makes a significant usability
> difference (in terms of number of mouse clicks/keystrokes) is to switch
> from plotting [Vec1]^2 to [Vec2]^2 to [Vec3]^2 etc... via simple
> mouseclick, without needing to edit the equation text in the lineedit.
> But I don't quite see in which workflow this would be useful. And if it
> really is useful for some people, then we could provide a plugin that
> takes a f(x) string and a vector as input, and computes y=f(x) (quite
> simple I think, at least with the muparser stuff that I used for the
> nonlinear fit plugin but probably also possible without that
> dependency). It would be redundant with the case of equations taking
> only one X vector, but we can keep them, if only for cases where we use
> more than one input vector (a case which by the way is not really
> handled with the current approach: what if you compute one vector based
> on two or more other vectors ?).
>
> So, to sum up this rather long and confusing discussion, my suggestion
> would be:
> - implement the changes as I suggest in bugzilla
> - provide a new plugin to compute y=f(x) taking a string (e.g. x^2) and
> a vector as input
> - keep equations as they are now for more than one input vector (or
> users reluctant to use plugins)
> - forget about the interpret x as... feature in equations (I wasn't even
> aware it existed and it does not "scale" to multiple vectors anyway)
>
> Does that sound acceptable ? I'd be willing to give a try at the plugin,
> using the muparser stuff already in the non-linear fit plugin, unless
> there is a preference for using kst "built-in" functionality to parse
> the f(x) string and compute the output vector.
>
> Nicolas
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst