Update status line during long computations

[Tom Goddard]

The Qt status line does not update with new status messages unless the Qt event loop is run. Want to avoid running the event loop since that can cause data being used for computations to be deleted.

Want this for giving progress when running the struts command on 1grl.

[Tom Goddard]

Fixed.

Added limited event processing to the MainWindow status() routine. Does not process user key / mouse events, but still could invoke timers and qt signals that might lead to unexpected side-effects from showing the status message. This is not a very satisfactory solution. I did not see anything on the web that would allow painting a Qt widget (status line) without doing event processing. The general advice for long calculations is to do them in a separate thread from the gui thread and notify the gui thread of progress. But this requires that the data used by the computation thread is protected from changes or deletions which is difficult to guarantee for molecular data.

[Tom Goddard]

The fix of calling Qt prcoessEvents(ExcludeUserInputEvents) unfortunately loses mouse up events when dragging the volume viewer contour level on the histogram and the map series slider. This makes those tools unusable because the drags continue to move the levels even after the mouse is released and a simple click and release often does not remedy the situation. This appears to be a but in Qt 5.7 since the documentation says mouse events are user events and they are not discarded. Qt 5.7 docs "ExcludeUserEvents: Do not process user input events, such as ButtonPress and KeyPress. Note that the events are not discarded; they will be delivered the next time processEvents() is called without the ExcludeUserInputEvents flag."

With this status line updating taken out, status message will not appear unless the event loop is run.

[Tom Goddard]

Eric reports that the ExcludeUserInputEvents flag to processEvents is ignored on Mac, determined by looking at Qt C++ source code.

Tested with status() using processEvents() with Qt 5.7.1 -- still loses mouse up event dragging volume threshold on emdb 1080.

[Tom Goddard]

It does not seem that ExcludeUserInputEvents is ignored, because if I take it out I get different behavior -- it does not lose mouse up events but dragging the volume threshold causes the indicator on the histogram to spastically move back and forth as if it moves right due to the drag and then the previous callback that changed the threshold resets it back to the left which is the current position. That may be cause by nested event loop evaluation.

[Tom Goddard]

THe lost mouse up events when using ExcludeUserInputEvents is Qt bug 53126 (May 2016)

​https://bugreports.qt.io/browse/QTBUG-53126

The same bug with lost key events with a better analysis of the problem is Qt bug 57718 (Dec 2016)

​https://bugreports.qt.io/browse/QTBUG-57718

which notes that the deferred user events are never processed on Mac, although you can get them processed by running QCoreApplication processEvents(). I tried that and it works (no lost mouse ups), but it also messes up the high priority redraw timer used to assure that the graphics is updated whenever a volume threshold change is made.

[Tom Goddard]

I put in code to work around the Qt bug described in the previous comment. It sets a timer and processes the deferred mouse/key events that are deferred by status message event loop processing.

The deferred event processing cause graphics not to update responsively when changing a volume threshold because the high priority timer that was used to make the redraw timer have higher priority than mouse events did not fire when processing deferred mouse events. So I changed the graphics updating during mouse drags for volume thresholds, planes, and time series to do an immediate redraw at each mouse step.