[Qt-interest] Correct way to manage the main event loop without QApplication::exec()

[Nikos Chantziaras]

On 03/19/2010 02:14 PM, Thiago Macieira wrote:
> Em Sexta-feira 19 Março 2010, às 12:33:35, Nikos Chantziaras escreveu:
>> I am using a library in my Qt program that has its own exec()-like
>> function.  In other words, its own event loop.  That function never
>> returns, but it calls callbacks I provide.  Those callbacks are the only
>> way to keep Qt's event loop rolling and to implement the GUI.  Note that
>> the library in question is not a GUI library and does not process any
>> system events; it does not perform any kind of system calls.
>>
>> Question is, how is this done correctly?  What problems can be expected
>> if I never call app->exec()?
>
> The proper way of doing this is to write your own QAbstractEventDispatcher and
> handle all Qt requests to register timers and socket notifiers in your 3rd-
> party library's exec-like function.

What I'm really asking I guess is what exactly QApplication::exec() is 
doing to prepare the event loop.  Right now, I simply call 
qApp->processEvents() whenever I get the chance.  But I'm doing that 
without ever having called QApplication::exec().  It does seem to work, 
but I simply don't know whether there are any complications besides this 
one:

   In event you are running a local loop which calls this
   function continuously, without an event loop, the
   DeferredDelete  events will not be processed.

I assume the part that says "without an event loop" means "without ever 
having called qApp->exec()".

Judging from the documentation of QAbstractEventDispatcher, I would have 
to subclass it if I wanted to integrate an external event loop into the 
application.  In this case, there's not really an external event loop. 
I described the 3rd party library's "exec" function as an "event loop" 
perhaps wrongly; it's actually a "processing loop", there are no events 
involved.  The only events that need to be processed are the Qt ones. 
The library simply calls callsbacks in order to perform functions like 
getting input from a user, but in an stdio-like fashion (i.e., not 
event-driven, the operation is supposed to *block* as far as the 3rd 
party library is concerned).  In that callback for example, I would 
bring up a QWidget-based widget where the user would enter some text or 
choose a file in a file dialog or press a button in a confirmation 
dialog.  Until the user finishes input (whatever of the above the input 
might be), I'm calling:

qApp->processEvents(QEventLoop::WaitForMoreEvents|QEventLoop::AllEvents);

And I also call processEvents() when the library needs to display some 
output (again, not event-driven).  And I would need to also take care 
the DeferredDelete events somewhere.

Do you still recommend that I should write my own 
QAbstractEventDispatcher if I can avoid it?