[Kstars-devel] A strange problem with qApp->processEvents()

Thomas Kabelmann thomas.kabelmann at gmx.de
Fri Aug 17 07:52:43 CEST 2007


Hi James,

qApp->processEvents() is a crutch for making the gui responsive if the program 
doesn't use threads for long operations. In Qt 3 it was not easy to write 
threaded code because there were several problems with the event loop. Now in 
Qt 4 that code was rewritten and is thread safe. So we can put that stuff 
like loading data in several threads without using such hacks like 
processEvents(). With KDE 4 comes ThreadWeaver that should simplify managing 
threads.

For the splash screen while reloading data, I like Jason's idea of putting a 
progress bar in the status bar. But that's only sensible if the gui stays 
responsive. So using threads would help us. But I think that's not stuff for 
KDE 4.0.

Regards,
Thomas

Am Freitag, 17. August 2007 schrieb James Bowlin:
> The QT docs described this as:
>
>   Processes all pending events according to the specified flags
>   until there are no more events to process.
>
>   You can call this function occasionally when your program is
>   busy performing a long operation (e.g. copying a file).
>
> http://doc.trolltech.com/4.3/qcoreapplication.html#processEvents
>
> This is exactly what I'm doing from within KSFileReader. For the
> star data, I call qApp->processEvents() every time 1% of the file
> has been read.  This has always worked fine during start up when
> the only window we have open is the splash window.
>
> If the user increase the faint magnitude limit of the stars, we
> read in the fainter stars from disk.  Unfortunately, calling
> processEvents() causes the skymap in the main kstars window to
> turn entirely light gray (the default background color).
> It gets repainted during the next draw cycle but this is still
> very disruptive.  If I don't call qApp->processEvents() then
> the splash screen can sometimes stay blank and the progress
> messages mostly don't show up.  I had added qApp->processEvents()
> calls to our code to fix these same problems in the original
> splash screen.
>
> I've narrowed the problem down to that call.  I don't even need
> a KStarsSplash window in order for it to happen.




More information about the Kstars-devel mailing list