[Kst] [Bug 141597] Change data file tool does not perform some updates

[Barth Netterfield]

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:
> ------- 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=141597
>
>
>
>
> ------- Additional Comments From nicolas.brisset eurocopter com  2007-02-22
> 15:11 ------- 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 ?
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst