Cocoa: Fix several issues with the event dispatcher

Autotest: qcoreapplication, qapplication, qtimer
qwidget_window, qwidget

Issue 1: stacking order of modal windows was not
working correctly. With this patch, we remove the
need for rebuilding modal sessions all the time,
and when we do, we rebuild them all in the correct
order.

Issue 2: When running the event processor manually
(that is, just calling processEvents in a loop), we
sometimes spendt 100% cpu if a window was pending to
become modal. The reason was that we need to keep
reposting the QCocoaRequestModal event until we
could block the calling thread (that is, one of
the exec flags was given to processEvents). With this
patch, the need for posting QCocoaRequestModal is
completly removed in favor of an 'interrupt'
approach instead.

Issue 3: If using Qt as a plugin, or just add widget
to a native cocoa application, it would often lead
to closing down the application. The reason is that
the event dispatcher needs to restart [NSApp run]
now and then. But this approach fails if Qt was not
the code that started [NSApp run] in the first place.
This patch removes the need to restart NSApp in this
situation, at the cost of modal windows not beeing
modal if Qt is not spinning the event dispatcher.
Normal QDialog::exec etc will always work.

1 files changed, 0 insertions, 4 deletions

diff --git a/src/gui/kernel/qapplication.cpp b/src/gui/kernel/qapplication.cpp
index fea3e2d..df85809 100644
--- a/src/gui/kernel/qapplication.cpp
+++ b/src/gui/kernel/qapplication.cpp
@@ -2311,10 +2311,6 @@ bool QApplication::event(QEvent *e)
         } else if (te->timerId() == d->toolTipFallAsleep.timerId()) {
             d->toolTipFallAsleep.stop();
         }
-#ifdef QT_MAC_USE_COCOA
-    } else if (e->type() == QEvent::CocoaRequestModal) {
-        d->_q_runAppModalWindow();
-#endif
     }
     return QCoreApplication::event(e);
 }