[Interest] Strange problem where exec() of dialogs returns immediately
thiago at kde.org
Sun Mar 11 18:58:47 CET 2012
On domingo, 11 de março de 2012 19.39.31, Nikos Chantziaras wrote:
> > Note how even you had to force an event loop by that horrible while (true)
> > construct. Remove it completely. Once you solve the problem of the last
> > window closing too soon, the main event loop will take care of the main
> > window's lifetime.
> It's not optimal, but needed.
No, it's not. It's wrong and you must get rid of it. There must be another
construct that avoids that mistake. It also has the mistake that you don't
have access to the quit flag, inside the loop, so you don't know when exiting
> The application is an engine for running
> programs in it, and those programs have their own internal event loops.
> They call callbacks so the host application can advance its own event
> loop. In those callbacks I then do processEvents(). There's no way
> around that.
Yes, there is. You can use threads or you can use a custom event dispatcher.
And this is assuming that you tried but was unable to integrate the loops by
way of timer and socket notifier callbacks. Your choice should be:
1) if the library provides you with callbacks for when it updates timers and
socket notifiers, use the standard Qt event loop
2) if the library does not provide that, but allows you to add sockets
notifiers and timers, then you should write your own Qt event dispatcher
(inheriting from QAbstractEventDispatcher) and register the Qt sources with
3) if the library does not provide either, you put its use in a thread
Anything else is sub-optimal because you'll either wake up too often or you'll
delay event processing. Or, more likely, both, which is worse.
> Even though I've dealing with this for years, I'm still not sure how to
> correctly advance Qt's event loop. For example is:
> qApp->sendPostedEvents(0, QEvent::DeferredDelete);
The correct way is app->exec() or loop->exec(), where loop is a QEventLoop
Everything else is workaround.
> even needed? I think it takes care of deleting objects (for
> deleteLater() calls), but seems to produce 100% CPU load on Mac OS X.
I explained above. You wake up too often.
As long as you use this sub-optimal construct, you'll use more CPU than you
need to and you'll delay processing. Find another way.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Interest