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

[Ross Bencina]

Hi Phillippe,

Good to hear it works for you. Sad to hear that the patch was never merged.. 
it was developed through the commercial support channel.

Ross.

----- Original Message ----- 
From: "Philippe"
Sent: Wednesday, May 04, 2011 11:39 PM
Subject: Re: [Qt-interest] gui disabled issue with PACE copy 
protectiondialogsinside Qt (OSX/Carbon)


> 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.