From 48fdd3facb4d67b29452281c2d43577a2f0cdac3 Mon Sep 17 00:00:00 2001 From: Richard Moe Gustavsen Date: Thu, 6 Jan 2011 09:44:22 +0100 Subject: Cocoa: add support for QEventLoop::ExcludeUserInputEvents Seems like this was just missing when used together with the DialogExec/EventLoopExec flags. This patch avoid using cocoas own run methods for dispatching events when we want to exclude user input events, and instead do it ourselves. This patch will only fix this issue when no modal windows are showing. For modal windows, a bit more research is needed. --- src/gui/kernel/qeventdispatcher_mac.mm | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gui/kernel/qeventdispatcher_mac.mm b/src/gui/kernel/qeventdispatcher_mac.mm index dc926e0..62c22a5 100644 --- a/src/gui/kernel/qeventdispatcher_mac.mm +++ b/src/gui/kernel/qeventdispatcher_mac.mm @@ -588,7 +588,10 @@ bool QEventDispatcherMac::processEvents(QEventLoop::ProcessEventsFlags flags) // manually (rather than from a QEventLoop), we cannot enter a tight // loop and block this call, but instead we need to return after one flush: const bool canExec_3rdParty = d->nsAppRunCalledByQt || ![NSApp isRunning]; - const bool canExec_Qt = flags & QEventLoop::DialogExec || flags & QEventLoop::EventLoopExec; + const bool canExec_Qt = + (flags & QEventLoop::DialogExec || flags & QEventLoop::EventLoopExec) + && !(flags & QEventLoop::ExcludeUserInputEvents); + if (canExec_Qt && canExec_3rdParty) { // We can use exec-mode, meaning that we can stay in a tight loop until -- cgit v0.12