[Qt-interest] QWidget::setCursor() and qApp->processEvents()

[Frank Hemer]

On Thursday 29 July 2010 13:56:27 Atlant Schmidt wrote:
> John:
>
>   No, Josh's problem is more fundamental and it's caused
>   one of those aspects of Qt that isn't obvious to the
>   newcomer.
>
>   Consider this pseudo-code activated by a signal:
>
>   MyClass::my_slot(void)
>     {
>       button_1->hide();
>       button-2->show();
>       button_3->disable();
>       button_3->show();
>       do_several_seconds_of_lengthy_computation();
>     }
>
>
>   When do the changes to the buttons appear to the user?
>   They appear *AFTER* the several seconds of lengthy
>   computation. This comes as a real surprise to many
>   folks, but it makes perfectly good sense once you
>   understand how Qt works.
>
>   Qt doesn't actually draw anything as you change the
>   status of the various buttons; it merely notes that
>   the buttons eventually need to be repainted. And it
>   will get around to doing all of that repainting, all
>   at once, once it gets back to its main event loop.
>
>   Ordinarily, this is a good thing; it "merges" multiple
>   changes that you might make to a single widget (as I
>   did with "button_3") and in that way it optimizes all
>   of the repaint activity. But if you do something like
>   Josh has done (or my pseudocode has done), it doesn't
>   have the effect you expected because you don't get
>   back to the Qt event loop in a timely fashion.
>
>   But forcing a repaint before the lengthy calculation
>   "flushes out" all of those pending repaint events so
>   the user can see them on the screen.
>
>   Alternatively, I'm coming to believe that any serious
>   Qt app really needs a separate thread handling the UI
>   so that the UI stays adequately responsive even in the
>   face of other work that the app is doing; all single-
>   threaded Qt apps are little more than nice demonstrations/
>   toys and unsuited for serious work.

Well explained - but I disagree with the conclusion.

It's not the gui stuff that should be moved to a separate thread.
Actually its the lengthy op stuff that should be moved to a thread and signal 
the app thread (which is the gui thread) when its done thus the display can 
be updated.

Frank