[Interest] Strange problem where exec() of dialogs returns immediately
realnc at gmail.com
Sun Mar 11 19:12:05 CET 2012
On 11/03/12 19:58, Thiago Macieira wrote:
> On domingo, 11 de março de 2012 19.39.31, Nikos Chantziaras wrote:
>> 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
> that lib.
> 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.
It provides neither. The callbacks are for doing graphics, audio and
user input. So threading is the only option. I didn't go that route
because you can't paint from a thread without using signals/slots, and
that seemed rather inefficient compared to direct calls.
But I guess I'll give it a try anyway. On modern hardware the overhead
is probably not noticeable.
More information about the Interest