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

[Karel Bassez]

Hi Ross,

I've submitted a bug report with code example of my case to the Qt bug
tracker at http://bugreports.qt.nokia.com/browse/QTBUG-15318

Perhaps it could be nice to try the same thing with a Carbon
NativeModalDialog implementation running in both Qt Carbon & Cocoa.

All the best,

Karel.

On Sun, Nov 14, 2010 at 1:59 AM, Ross Bencina <rossb-lists at audiomulch.com>wrote:

>  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 <bassez.karel at gmail.com>
> *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
>>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20101114/b7f961ac/attachment.html