Bug 89844

Summary: New data are loaded when paused if you edit plots
Product: [Applications] kst Reporter: Matthew Truch <matt>
Component: plottingAssignee: kst
Status: RESOLVED FIXED    
Severity: normal    
Priority: HI    
Version: 1.x   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Matthew Truch 2004-09-20 01:00:47 UTC
Version:           1.0.0_devel (using KDE KDE 3.2.3)
Installed from:    RedHat RPMs
OS:                Linux

When paused, and reading to end of file (with 'live' data), applying any edit to a plot (including just changing labels), the data is loaded to the current time, as if the pause button is pressed twice quickly in sucession.  

How to reproduce:
Read live data, make sure you are reading to end of file.  
Pause kst.
Edit a plot and change a label.  
Apply edits.
Notice how the data is updated (although kst stays paused).

Expected behavior:
kst doesn' load the newest data as we are paused, but is still able to change labels and the such.
Comment 1 George Staikos 2004-09-22 20:50:04 UTC
Does it make sense to never update data sources when Kst is paused?  if so, that would be the fix.  However just not updating on plot dialog changes is rather broken by design.  The problem is deciding what should and should not be updated, and basically I think we can define it to when should all objects be updated, and when should all objects except rvectors be updated.  Until this is decided, I can't really fix this bug.
Comment 2 Matthew Truch 2004-09-23 18:41:29 UTC
Well, here's the case I was coming from:  
Looking at live data.  Something interesting happens, and I want to print or export to an image, but first I want to make some cosmetic changes (change label text or plot colors or something).  I hit pause, edit the plots attributes, apply edits, and because new data is loaded, the 'interesting' event is gone.
Comment 3 Netterfield 2004-09-23 18:50:47 UTC
I think that 'pause' should produce prohibit updating of data-sources (even with force set), but should allow everything else to behave as if 'pause' were not set.

This would mean that plot edits, adding curves, range changes get updated, but no new data gets noticed until pause is unset.  Of course this would prohibit even manually trying to look at new data, but I think that is OK.
Comment 4 George Staikos 2004-09-24 08:25:11 UTC
CVS commit by staikos: 

Does this solve the update issues?  If so, are there any conceivable cases
where we would still want to be able to force an update of data sources?

CCMAIL: 89844@bugs.kde.org


  M +12 -10    updatethread.cpp   1.28


--- kdeextragear-2/kst/kst/updatethread.cpp  #1.27:1.28
@@ -138,4 +138,5 @@ bool UpdateThread::doUpdates(bool force,
 
   // Update the files
+  if (!_paused) { // don't update even if paused && force
   KST::dataSourceList.lock().readLock();
   unsigned cnt = KST::dataSourceList.count();
@@ -145,5 +146,5 @@ bool UpdateThread::doUpdates(bool force,
     dsp->update();
 
-    if (_done || (_paused && !force)) {
+      if (_done) {
       KST::dataSourceList.lock().readUnlock();
 #if UPDATEDEBUG > 1
@@ -154,4 +155,5 @@ bool UpdateThread::doUpdates(bool force,
   }
   KST::dataSourceList.lock().readUnlock();
+  }
 
   { // scope to destroy the temporary list


Comment 5 Matthew Truch 2004-09-27 00:59:42 UTC
This doesn't quite solve all the issues.  My test case: Looking at live data; paused.  Open edit plots, and edit the legend (I just alternate between show and disable), clicking on apply edits to see if the plots update (ie legend appears and disappears) and the curves do not.  

Right now, the first few times I click apply edits, the curves will update, and then after that, they will not.  Few is random, and is usually between 1 and 5.  Once the curves stop updating, I can close and reopen the edit plot dialog and make changes and the curves don't update.  If I unpause and re-pause, the process starts over.  
Comment 6 George Staikos 2004-11-02 01:17:40 UTC
Sorry, can't reproduce this anymore.  If you still have a problem, please reopen it with more detail. #5 definitely can't be reproduced.