Summary: | Read to End should use reqnframes not nframes | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | D. V. Wiebe <dvw> |
Component: | general | Assignee: | George Staikos <staikos> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 1.0.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
D. V. Wiebe
2004-12-01 02:51:29 UTC
I don't understand. Do you want the number of frames to be consistent, reading from the end? If so, then that should be "Count from end". If you want the starting frame to always be X, you should use "Read to end". Is there something other than this that you want? I think an example of the idea is this: You open a live data source with -n 1000, but when you open it, there are only 100 frames in it. You see all 100 frames, with the displayed range growing. If you did nothing, the range would keep expanding, until you see frames 0 - 999, then things would start scrolling (1-1000, 2-1001, etc...) But, when the file is only 500 frames long, you hit 'read from end'. Now you start scrolling, limited to 500 frames (1-500, 2-5001, etc). The correct behavior would have been to not change the requested number of frames, but to only set count from end (which was already set in this case). This example is not a big deal, but if you have multiple data sources, etc, it could be. On December 6, 2004 12:35 am, George Staikos wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=94193 > > > > > ------- Additional Comments From staikos kde org 2004-12-06 06:35 ------- > I don't understand. Do you want the number of frames to be consistent, > reading from the end? If so, then that should be "Count from end". If you > want the starting frame to always be X, you should use "Read to end". Is > there something other than this that you want? > _______________________________________________ > Kst mailing list > Kst@kde.org > https://mail.kde.org/mailman/listinfo/kst Yeah, Barth basically has what I mean. My sequence of events is: 1. Starting with a kst reading a streaming datasource, I pause kst. (This is to give the CPU an opportunity to do something else besides plot data, for instance: drawing dialog boxes.) 2. Set Number of Frames in the Change Data Samples dialog to something larger than the current number of frames in the datasource. So, if there are now 1000 frames, I set this to 2000. I do this not to be perverse, but because I really do want to look at the last 2000 frames in the stream. 3. Hit Read to End to get things moving and up to date again. When I do step 3, kst immediately changes that 2000 I just went through the trouble of inputting into the number of frames currently in the file, which might be, say, 1023, now. This is really, really annoying, 'cause when I told kst I wanted to look at the last 2000 samples, I wasn't trying to be coy: I really meant it. My options are now either wait until the datasource has passed the 2000 samples mark and then go back and repeat steps 1-3 or try updating the Change Data Samples dialog while kst is running. (The latter is especially advantageous around lunchtime, since waiting for the dialog box to get drawn affords me the opportunity to eat lunch, and perhaps take a brief nap.) In the vast majority of cases it's not an issue, since the datasources I'm looking at are much longer than the amount of data I actually want to have plotted. Ah so it's Read From End... not to End. Got it. :-) CVS commit by staikos: Read From End should not change the number of displayed samples unless there is an inconsistent state. BUG: 94193 M +7 -11 kstdoc.cpp 1.140 M +10 -0 kstrvector.cpp 1.67 M +3 -0 kstrvector.h 1.27 --- kdeextragear-2/kst/kst/kstdoc.cpp #1.139:1.140 @@ -657,4 +657,5 @@ void KstDoc::samplesUp() { for (int i = 0; i < (int)rvl.count(); i++) { V = rvl[i]; + V->writeLock(); f0 = V->reqStartFrame(); n = V->reqNumFrames(); @@ -670,4 +671,5 @@ void KstDoc::samplesUp() { } V->changeFrames(f0, n, skip, doSkip, doAve); + V->writeUnlock(); } @@ -687,4 +689,5 @@ void KstDoc::samplesDown() { for (int i = 0; i < (int)rvl.count(); i++) { V = rvl[i]; + V->writeLock(); f0 = V->reqStartFrame(); if (f0 == -1) @@ -703,4 +706,5 @@ void KstDoc::samplesDown() { V->changeFrames(f0, n, skip, doSkip, doAve); + V->writeUnlock(); } @@ -713,19 +717,11 @@ void KstDoc::samplesDown() { void KstDoc::samplesEnd() { KstRVectorPtr V; - int f0, n, skip; - bool doSkip, doAve; - int fileN; KstRVectorList rvl = kstObjectSubList<KstVector,KstRVector>(KST::vectorList); for (int i = 0; i < (int)rvl.count(); i++) { V = rvl[i]; - f0 = -1; - n = V->numFrames(); - skip = V->skip(); - doSkip = V->doSkip(); - doAve = V->doAve(); - fileN = V->fileLength(); - - V->changeFrames(f0, n, skip, doSkip, doAve); + V->writeLock(); + V->setFromEnd(); + V->writeUnlock(); } --- kdeextragear-2/kst/kst/kstrvector.cpp #1.66:1.67 @@ -230,4 +230,14 @@ void KstRVector::changeFrames(int in_f0, } +void KstRVector::setFromEnd() { + ReqF0 = -1; + if (ReqNF < 2) { + ReqNF = numFrames(); + if (ReqNF < 2) { + ReqF0 = 0; + } + } +} + KstRVector::~KstRVector() { _file = 0; --- kdeextragear-2/kst/kst/kstrvector.h #1.26:1.27 @@ -109,4 +109,7 @@ public: KstDataSourcePtr dataSource() const; + /** Read from end */ + void setFromEnd(); + private: KstObject::UpdateType doUpdate(bool force = false); |