Bug 372265

These automatic strings automatically created by the data source are the problem.  This is not (under the hood) a DataScalar, so it never shows up in the list of things to change when you change datasources.

A work around for now is to create->string and then create a data string from the data source from field FILE.  This properly updates when you "change datasource".
However, you have to hit reload to actually redraw it.  I was working on fixing that on the way into work this morning.

What to do with the automatic scalars and automatic vectors is more problematic.  
-How valuable are these automatic scalars/vectors.  Would it be better to just create them with create->scalar and create->string so they are consistent with everything else?  There should be create scalar and create string shortcut icons in the label dialogs in any case.

Hi Barth,

WRT the automatic scalars and vectors, I have not found them to be very useful so, if it makes the code easier, then I would be okay with creating them manually.

I have tried your work around and it kind of works but not quite. If I change data files manually the "data strings" update as expected but if I run Kst from the command line using the following script the "data strings" are not updated.

@echo off
for %%f in (*.csv) do (
echo "%%f"
"path\to\kst\kst2.exe" -F "%%f" --png "%%~nf.png" --pngWidth 3840 --pngHeight 2160 "kstfilename.kst"
)

Is there a way to force Kst to refresh the "data strings" prior to exporting an image file?

Regards, Ben

Hi all,

I believe automatic scalars are useful and I would not like having to create them manually. For instance, they can be used to display some stats in text form along with a graphical plot. For me they should be preserved, and of course recomputed and labels using them (if any) refreshed automatically when the data is reloaded from the same file - or from another file.

The same should essentially happen with strings from datasources in my opinion.

Where it gets more tricky is when you have more than one datasource. In that case we have to keep track of which datasource provides which object to be able to update the right one(s) in case one of the datasources change.

Git commit 1a1005423d9eb7f9f20bb2edc7f98ffc000c1552 by Barth Netterfield.
Committed on 30/11/2016 at 23:56.
Pushed by netterfield into branch 'master'.

-F also changes data strings, data scalars, & data matrixes.

M  +5    -0    src/libkst/matrixfactory.cpp
M  +4    -0    src/libkst/scalarfactory.cpp
M  +4    -0    src/libkst/stringfactory.cpp

https://commits.kde.org/kst-plot/1a1005423d9eb7f9f20bb2edc7f98ffc000c1552

OK.

as of the next commit, I (will) have fixed data strings and data scalars so 
that they are saved properly, and so that -F and the change data source both 
work for them as expected.

Now we have to decide what to do with the datasource automatic primitives:

I think there are three options:
1) they are permanently associated with the  datasource.  eg:
	[tmp.dat (DS1):FRAMES (X1)]
is the number of frames for the file tmp.dat - now and forever.  -F doesn't 
change this.  Change datasource doesn't change this.  Saving and reloading 
doesn't change this.  The primitives can not be edited in any way.
With the exception of some minor bugs, this is the logic of how they have been 
implemented.

2) When a datasource is first used, all of the primitives associated with the 
datasource are automatically created as normal datascalars or datavectors.  
They now show up as normal primitives in all of the dialogs, and can be 
optionally edited and changed just like any other dataprimitive, including in 
the change datasource dialog, or -F.  However, since they are just 
automatically created normal data primitives, "purge" would delete them 
(unless we add some sort of flag to them).

We would have to decide which strings and scalars from a datasource should be 
created automatically, and which ones should be left to manual creation.
This requires some (tractable) new code.

3) automatic strings and scalars are removed alltogether.  If you want them, 
you create them, just like any other datascalar or datastring.

(In any case we should add create string/scalar icons to text entry dialogs.)

thoughts?

cbn
On Wednesday, November 30, 2016 9:15:07 PM EST Nicolas Brisset wrote:
> https://bugs.kde.org/show_bug.cgi?id=372265
> 
> Nicolas Brisset <nicolas.brisset@airbus.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> CC|                            |nicolas.brisset@airbus.com
> 
> --- Comment #3 from Nicolas Brisset <nicolas.brisset@airbus.com> ---
> Hi all,
> 
> I believe automatic scalars are useful and I would not like having to create
> them manually. For instance, they can be used to display some stats in text
> form along with a graphical plot. For me they should be preserved, and of
> course recomputed and labels using them (if any) refreshed automatically
> when the data is reloaded from the same file - or from another file.
> 
> The same should essentially happen with strings from datasources in my
> opinion.
> 
> Where it gets more tricky is when you have more than one datasource. In that
> case we have to keep track of which datasource provides which object to be
> able to update the right one(s) in case one of the datasources change.

Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!