On Wednesday 21 July 2004 00:00, Matthew Truch wrote:
> Now that kst is (partially?) threaded, the user interface continues to run
> when kst is busy (ie when you click 'next page' when your data has ~1000000
> points per page), which is confusing.  There should be some kind of visual
> indicator (busy cursor, or better, an indicator on the status bar (which
> normally just says "Ready")) letting one know when things are being worked
> on in the background.  When looking at live data, this indicator should
> pulse as new data arrives (and is processed).

  We agree.  It's part of our "TODO" list.

*** Bug 88078 has been marked as a duplicate of this bug. ***

We now have the ability to display status messages and a progress indicator to denote that Kst is busy. Just need to call it in the appropriate places.

Are there race condition issues here?  are they repairable? Can we just use the existing hooks, or is this un-fixable in the near term...

Kst now has an "I'm busy" indicator.
Bug 91693 has some examples of where it should be used.

Why aren't you reading the comments?  The existing solution is broken.

Could you explain which comments you are talking about? 
The ones from Barth, which ask if there are problems, and which received no response?
What is broken about the existing solution?

Re: [Kst] kdeextragear-2/kst/kst


From: George Staikos <staikos@kde.org>
To: kst@kde.org
Date: 08/11/04 15:38
On Wednesday 11 August 2004 14:50, Andrew Walker wrote:
> CVS commit by arwalker:
>
> Added a progress bar and progress string indicator to the status bar.
> Use the aforementioned to display the progress of the data wizard.

  This is exactly why we shouldn't include this code in CVS yet.  
processEvents() is going to cause us huge nightmares because we will receive 
update events from the threads, among other things.  I spent lots of time 
removing these because of the crashes and bugs they introduced in the past.

+void KstApp::slotUpdateProgress(int iTotal, int iStep, const QString &msg) {
+  if (iStep > 0) {
+    if (!_progressBar->percentageVisible()) {
+      _progressBar->setPercentageVisible(true);
+    }
+    if (iTotal != _progressBar->totalSteps()) {
+      _progressBar->setTotalSteps(iTotal);
+    }
+    _progressMsg->setText(QString::null);
+    _progressBar->setProgress(iStep);
+    _progressMsg->setText(msg);
+  } else {
+    _progressBar->setPercentageVisible(false);
+    _progressMsg->setText(msg);
+    _progressBar->reset();
+  }
+
+  while (kapp->eventLoop()->processEvents(QEventLoop::ExcludeUserInput));
+}
+
+

Lets see if I can get the story correct:

At the end of [Data Wizard] we start doing something slow, which we keep track 
of with the progress bar.

The progress bar calls exec() on each progress bar update, which processes 
events.

The loading is slow.  While the loading is going on, the user does something 
(eg, deletes a vector which is being loaded, but which has not yet been made 
into a curve).  

Since exec() is being called, the event gets processed, which puts us into an 
inconsistent state.  BadThings(tm) happen.

Is this possible?  Is this what was causing trouble?

All well and good. But the code snippet that George included is out of date and does not have a call processEvents() any longer, and hasn't for some time. The necessity for this call was removed by my addition of KstQuickProgressBar.

I'm not sure what Barth means when he refers to a call to exec.

So, do we still have a problem?

Ah great, it was changed while I was away and I never received a response to that email so I had no idea.  Looks fine to me now.  What remains is to remove the other two progress dialogs and their event processing which is equally dangerous though perhaps less likely to cause a crash since they are for much shorter operations than, ex, the data wizard.

So can this bug be closed now and any remaining changes moved to bug #91693?