[Qt-interest] gui disabled issue with PACE copy protection dialogsinside Qt (OSX/Carbon)

[Philippe]

Just read your solution many months after you posted it, and indeed I
confirm this is a good finding and fix (4.7.2)...

Philippe

On Tue, 20 Jul 2010 02:20:19 +1000
"Ross Bencina" <rossb-lists at audiomulch.com> wrote:

> Replying to my own message for the benefit of the next unfortunate soul who 
> comes accross this bug...
> 
> Apparently Qt/Carbon's QApplicationPrivate::globalEventProcessor() function 
> was implemented with the assumption that the only windows in the application 
> would be created by Qt. As a result, it eats kEventWindowActivated and 
> kEventWindowDeactivated events for non-Qt windows, which the PACE iLok 
> dialog (naturally) expects to recieve. This is a pretty bad bug in Qt, I was 
> lead to believe it would leave events alone which were destined for non-Qt 
> Windows.
> 
> In any case, here's a patch if anyone ever needs it. It sets handled_event 
> to false if the event is not associated with a QWidget:
> 
> -- 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;
>          }
> 
> 
> Now my plugin's PACE dialog's activate correctly.
> 
> Would be nice to hear from someone who can explain why this wasn't done 
> right in the first place.
> 
> I now suspect that it's also eating mouse (and perhaps other) events under 
> some conditions since I have some plugin windows which don't respond to 
> mouse events, and some that don't always redraw. If anyone is working on 
> more patches/fixes for this kind of thing I'd love to hear about it.
> 
> Thanks
> 
> Ross.
> 
> ----- Original Message ----- 
> From: "Ross Bencina" <rossb-lists at audiomulch.com>
> To: "Qt-Interest" <qt-interest at trolltech.com>
> Sent: Wednesday, July 14, 2010 9:21 PM
> Subject: [Qt-interest] gui disabled issue with PACE copy protection 
> dialogsinside Qt (OSX)
> 
> 
> > Hi Everyone
> >
> > My Qt app hosts plugins developed by 3rd party developers. Some plugins 
> > use
> > PACE copy protection (paceap.com). The problem is, when they get loaded 
> > they
> > display an iLok or PACE dialog and then hang with all of the buttons on 
> > the
> > PACE dialog disabled. This is a non-Qt dialog that the copy protection 
> > code
> > displays. As far as I can tell, the dialog is running its own nested event
> > loop, although a few things in my Qt UI are still active (hover, some
> > clicks, tooltips). This is on OSX.
> >
> > I have only tested this with demo versions of plugins but my users are
> > reporting similar problems with their licenced versions. If I try to use 
> > gdb
> > naturally PACE exits immediatly so it's hard to even give info about 
> > threads
> > etc.
> >
> > I am guessing that Qt might be doing something (or not doing something) 
> > with
> > event processing that is causing this but I wonder whether anyone has
> > encountered this before and has any ideas how I might solve it. I guess
> > there would be similar issues in displaying any 3rd party dialog inside a 
> > Qt
> > GUI.
> >
> > Any and all thoughts and help appreciated.
> >
> > Many thanks
> >
> > Ross.
> >
> > _______________________________________________
> > Qt-interest mailing list
> > Qt-interest at trolltech.com
> > http://lists.trolltech.com/mailman/listinfo/qt-interest 
> 
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest