Backport PR
#2294: inputhook_qt4: Use QEventLoop instead of starting up the QCoreApplication...
Backport PR
#2294: inputhook_qt4: Use QEventLoop instead of starting up the QCoreApplication
I referenced this branch in
#2080 and was letting it sit for a little while, but I have decided to make it a full pull request to get some additional visibility.
Essentially our Qt event loop mechanism repeatedly starts and quits a `QCoreApplication` object. Unfortunately the `QCoreApplication::quit` slot has a lot of unintended side effects (like emitting an `aboutToQuit` signal which closes all open file dialogs).
For our input hook, we _might_ be able to get by with just using a `QEventLoop` whose quit slot is much simpler and less destructive.
For a little bit of background on why one might want to just use `QEventLoop::exec`, let's examine what `QCoreApplication::exec` does:
```c++
int QCoreApplication::exec()
{
if (!QCoreApplicationPrivate::checkInstance("exec"))
return -1;
// ... [some assertions]
threadData->quitNow = false;
QEventLoop eventLoop;
self->d_func()->in_exec = true;
self->d_func()->aboutToQuitEmitted = false;
int returnCode = eventLoop.exec();
threadData->quitNow = false;
if (self) {
self->d_func()->in_exec = false;
if (!self->d_func()->aboutToQuitEmitted)
emit self->aboutToQuit();
self->d_func()->aboutToQuitEmitted = true;
sendPostedEvents(0, QEvent::DeferredDelete);
}
return returnCode;
}
```
As far as I can tell, it's a small wrapper around `QEventLoop::exec` which also:
* Sets some variables regarding the current status
* Emits an `aboutToQuit` signal right before the function returns (which is the root cause of @denisri's problem in
#2080).
Historically, our Qt event loop is a python implementation of the (win 32) input hook supplied with the PyQt4 source (see qtcore_input_hook` in `python-qt4/sip/QtCore/qcoreapplication.sip`), which more or less dates to a [mailing list post](
http://www.riverbankcomputing.com/pipermail/pyqt/2007-July/016512.html) from July 2007.
