Bug 141597

Created attachment 19642 [details]
Test case

Files for the test case, don't forget to change the ASCII datasource
configuration.

I've fixed some of the problem by properly updating in the Data Manager, but there remains a tricky issue with equations.

If you have an equation using variables and you change the name of those variables, the equation clearly won't work. In the equation in the bug.kst file ([DS-manche3.see/P2]-[DS-manche3.see/R2]), both vectors have the filename in their tags. When we change the data file for P2, it's full tag changes to "DS-manche1.see/P2".

We're not sure exactly how to deal with this, but we've had several ideas.

1. Don't change the vector tags when the datasource changes.
     - This fixes equations but is nasty for pretty much everything else.
       The view ... dialogs will all have misleading hierarchies and it'll be
       very hard to tell what's going on.

2. When building equations, only insert the display tags for the vectors into the equation string.
     - This will break if those names become non-unique (i.e. insert
       DS-manche3.see/P2 so equation becomes "[P2]", then create
       DS-manche1.see/P2). The equations will then be unresolvable.

3. When changing object names, check if they are used in equations and update the equations to use the new names.
     - This changes the current semantics of equations, where the text of the
       equation is independent of the current data objects in memory.
     - It is also potentially tricky and/or expensive to identify where objects
       are used (equations, events, etc.).

OK, so we keep coming back to this "namespacification" problem. If I understand it correctly, this is the same conceptual problem as we started discussing on the list wrt to how full/short names are handled for metadata used in labels. My reasoning below is based on metadata used in labels, but I think it can be generalized to equations. I know it is hard to follow from a textual explanation, but this is a major issue to me and I think we need to solve it properly for 1.4.0, so that I took some time to explain my point of view ! Read on if you dare...

I like the idea that:
- a short name is enough as long as it is unique
- a long name can be used to disambiguate and should probably be preserved, unless the user explicitly asks for it to be changed. Now the question is: how can he ask that ?

I've been thinking about this issue quite a bit, and I think there is only one bullet-proof solution: ask the user! Let me explain... Suppose you have data files file{1,2,3,...}.dat, based on the same template, with identical metadata tags (say meta1, meta2). Now, a couple of scenarii:
1) I create a couple of plots from file1.dat, with some labels using [meta1]. If I want to see the same results with file2.dat I'll use the change data file tool in replace mode, and the metadata gets updated: all is fine.
2) I notice something strange with file2.dat and want to compare with file1.dat, superimposing the two sets of curves. I use the change data file tool again, in duplicate mode this time. My labels break since [meta1] is no longer unique. At least I notice something's wrong and I can fix it. I'll just put a long name to resolve the ambiguity, the question is which: [DS-file1.dat/meta1] or [DS-file2.dat/meta1] ? And how kst could save the user the hassle of typing such potentially long names... see below :-)
3) Suppose I have settled on [DS-file1.dat/meta1] above, and now realize I may have the same problem in file3.dat. I fire up the change data file tool, replace all vectors and dependents from file1.dat with their file3.dat counterparts (say I want only two sets of curves and keep file2.dat visible). The label is gone since [DS-file1.dat/meta1] no longer exists. So you may ask: "OK, why not change the DS-... prefix when using the change data file in replace mode ?" Could be an option, but what if I only replace the first ten vectors provided by file1.dat and keep others ? The label is not attached to vectors, so there is no way to figure out whether it should change or not. Only the user knows it... that's why my suggestion is the following:

*** Add an intermediate dialog (or integrate it in the existing UI) ***
this dialog would present a list of objects depending on the vectors(s)/datasource(s) being substituted. I imagine something like:
- a listbox or rather listview (in extended selection mode :-)) titled "Select objects you wish to update" with a list of elements depending on vectors being substituted or duplicated and their type (e.g. equation/label/plugin...). All objects would be preselected by default, as I guess in 99% of cases and based on my experience, that's what the user will want
- buttons to add all/remove all/ from the selection

In fact, to sum up this long comment the idea is to add some UI to ask the user which "paths" should be changed automatically by kst. If all are selected by default, I guess in most cases there won't even be the need for more than one extra mouse click and at least everything will be possible, and clear. The biggest issue might be the UI/real estate...

It sure isn't an easy issue ! Thoughts ?

This problem also relates to changing the tagname of a vector.
Imagine that I had a bunch of plots based on field N15C7 (filtered, a psd, an 
equation...) and I decide to change root vector to look at field N15C6.  I 
decide to also change the tag name of the vector so that I'm not confused.
What should happen to all the dependent data objects?

On Wednesday 21 February 2007 6:06:51 pm Eli Fidler wrote:
> ------- Additional Comments From eli staikos net  2007-02-22 00:06 -------
> I've fixed some of the problem by properly updating in the Data Manager,
> but there remains a tricky issue with equations.
>
> If you have an equation using variables and you change the name of those
> variables, the equation clearly won't work. In the equation in the bug.kst
> file ([DS-manche3.see/P2]-[DS-manche3.see/R2]), both vectors have the
> filename in their tags. When we change the data file for P2, it's full tag
> changes to "DS-manche1.see/P2".
>
> We're not sure exactly how to deal with this, but we've had several ideas.
>
> 1. Don't change the vector tags when the datasource changes.
>      - This fixes equations but is nasty for pretty much everything else.
>        The view ... dialogs will all have misleading hierarchies and it'll
> be very hard to tell what's going on.


Doesn't deal with the above problem.  BAD.

> 2. When building equations, only insert the display tags for the vectors
> into the equation string. - This will break if those names become
> non-unique (i.e. insert DS-manche3.see/P2 so equation becomes "[P2]", then
> create
>        DS-manche1.see/P2). The equations will then be unresolvable.


BAD!

> 3. When changing object names, check if they are used in equations and
> update the equations to use the new names. - This changes the current
> semantics of equations, where the text of the equation is independent of
> the current data objects in memory. - It is also potentially tricky and/or
> expensive to identify where objects are used (equations, events, etc.).


This, I think, is the behavior we are suppose to currently have with other 
data objects (eg, psds).  It is the most complicated solution, but from the 
user's point of view, the best.

An implementation suggestion: When an equation string is submitted to the 
KstEquation, the KstEquation does an internal replacement of vector names 
with its own internal code eg, [{V1}] or some such, and keeps a list of 
KstVectorPtrs which these refer to.  When filling the equation text edit in 
the dialog, it does a replacement with the vector's tag names.  Do the same 
thing for scalars.  IIRC, KstEquations already have the list of vectors which 
the equation depends on.

Scalars in labels have the same issue as equations: what to do?
I think we treat the labels the same way we treat equations.  List of used 
vectors and used scalars:  Tag Name replacement for dialogs and saving.


More related questions: 

1) do we change the tag-names of dependent data objects which are using 
automatically generated tag names?
-Nicholas has suggested that KstObjects be able to have a special dynamic 
automatically generated tag name.  If the user changes it, it ceases to be 
automatic (unless the user re-automatizes it).  I like this a lot!  

It seems to me that we are moving to a place where we *never* refer to a data 
object by its tag name internally; only in the UI, and only by its current 
name.

So... what does this all do for the schedule of releasing 1.4?
hmmm...

Meta-data refers to data sources.  If you have a label which refers to 
metadata, then changing the data source certain vectors shouldn't be expected 
to change the Meta-data tags... unless, as you suggest, you ask it to.

The two places you might ask it to are the change-datasource for vectors 
dialog, and your new dialog.  The problem is that labels names are currently 
cryptic at best!

I think we should open a devel-doc which defines what the UI for all this 
could look like.

cbn

On Thursday 22 February 2007 9:11:17 am Nicolas Brisset wrote:
[bugs.kde.org quoted mail]

I've just tried the latest svn, and there is still quite some confusion when doing the steps originally reported (data not being refreshed with the new values until you hit reload, and equation text in the data manager UI still showing the old strings, until you try to change the equation).
It looks like this whole issue still needs careful consideration... Now that Eli seems to be back, hopefully we can converge quickly ? Eli, do you have a proposal based on our latest comments ?

With this example, usually, on apply or ok, nothing happens until you, in some way, generate a redraw (eg, resize the window).  I made a different example and it worked fine.

The equation details are not changed in the data manager until the equation is opened for editing, and then OKed.  But the equation's data seems correct.

This has been resolved as part of the numerous fixes to the hierarchical naming convention.