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

[Andre Somers]

Op Wo, 4 mei, 2011 3:52 pm, schreef 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.

Sad indeed. Perhaps you can try to push Digia to use their traction,
and/or keen an eye on the OpenGovernance initiative to make it easier to
get this in yourself.

André


> ----- 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.
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>