[Qt-interest] Qt Cocoa, QMenu and third party modal dialogs

[Ross Bencina]

Hi Karel

I had/have similar problems with Qt/Carbon (especially PACE dialogs)

http://lists.trolltech.com/pipermail/qt-interest/2010-July/025801.html

I did track down some issues with Qt's event handling -- basically Qt was not dispatching events to windows that Qt hadn't created/didn't know about. Under Qt /Carbon Qt installs global event hooks with the OS and uses these to dispatch events to Qt windows (and sometimes drops events to non-Qt windows). Here's the relevant part of what I sent to Support:

> The following patch resolves the issue with activate/deactivate events. It
> sets handled_event  to false if the event is not associated with a QWidget so
> that the non-Qt dialog recieves it. It resolves the issue with PACE dialogs
> hanging:
> 
> -- qapplication_mac.4.6.3.mm 2010-06-02 12:00:19.000000000 +1000
> +++ qapplication_mac.mm 2010-07-20 08:04:33.000000000 +1000
> @@ -2327,9 +2327,16 @@
> }
> QMenuBar::macUpdateMenuBar();
> }
> +
> +   if( !widget )
> +    handled_event = false;
> +
> } else if(ekind == kEventWindowDeactivated) {
> if(widget && QApplicationPrivate::active_window == widget)
> app->setActiveWindow(0);
> +
> +   if( !widget )
> +    handled_event = false;
> } else {
> handled_event = false;
> }
> 
> 
> But I think the bug is not just with activate/deactivate events as some hosted
> plugins are also not receiving mouse events in their plugin windows, and the
> mouse event handling code in globalEventProcessor() seems to try very hard to
> find an associated QWidget for events which may be destined for another
> window.
> 
> Could you please clarify what guarantees are made with regard to Qt/Carbon's
> handling/filtering of events to non-Qt windows and review
> QApplicationPrivate::globalEventProcessor() to ensure it doesn't eat mouse
> events destined for non-Qt windows -- looking at the code it doesn't even seem
> that this option was considered. Please provide a patch.

I was able to resolve some (but not all) of these issues with Qt Support. But they wanted a test case to take it further, I never got around to submitting a test case so I'm not sure this issue made it into the bug tracker. 

I don't know if a similar fix could be applied in Cocoa (or if the same code is shared by Qt Cocoa and Carbon) but you might want to check through Qt's event dispatch mechanism to make sure that Qt/Cocoa isn't cancelling/dropping events for non-Qt windows.

I'm very keen to see the bigger issue of correct native/alien window event dispatch fixed upstream since obviously it makes hosting 3rd-party plugins unreliable. Perhaps we can look at submitting some test cases to the Trolls.

HTH

Ross.





  ----- Original Message ----- 
  From: Karel Bassez 
  To: qt-interest at trolltech.com 
  Sent: Sunday, November 14, 2010 9:19 AM
  Subject: Re: [Qt-interest] Qt Cocoa, QMenu and third party modal dialogs


  Bump?


  On Fri, Nov 12, 2010 at 5:32 PM, Karel Bassez <bassez.karel at gmail.com> wrote:

    Hi,

    I'm developing a Qt Cocoa application that hosts non-Qt, third party plugins. Some of these plugins pop up a modal dialog during initialization or loading of data. However this seems to interfere with Qt's event loop, causing these modal dialogs to be unresponsive and unable to close. I've tracked down the problem to Cocoa's abortModal basically not being executing properly. This behavior often seems to be triggered by invoking these plugin init/load functions from a popup QMenu. I've tried some tricks like invoking the menu's actions using a queued connection, which helps in some cases, but also sometimes causes a messagebox popped by such third party plugin to be automatically clicked on its default button in some cases. So either it freezes up or is a bit overzealous. My guess is that the modality of the popup QMenu comes into play here, since doing these same actions from the main application menu doesn't cause this behavior. Please mind that I do not have any control over these plugins.

    Thanks for any possible help,

    Karel



  -- 
  Karel Bassez
  Software Engineer
  Vienna Symphonic Library GmbH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101114/df2dc6b2/attachment.html