I would like to display some header information on a plot and have that information update as the underlying data file changes. Currently this does not work for me. Using a text box I can display information (string data) contained in the header of my data file. The link to this header information requires the file name of the data file. When using the "Change Data File" function the file name reference in the text box is not updated to the new data file name and the link is broken.
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!