> Am 26.11.2014 um 20:17 schrieb John Weeks <j...@wavemetrics.com>:
> 
> I am seeing confusing QEvent::WindowActivate events associated with floating 
> windows on Macintosh. 

I'm by far no Cocoa expert, but when looking at the debug output pattern it 
really seems that Qt is getting "spontaneous" Activate events.

So for instance after windows B has been created we get yet another "Activate" 
event for Windows A (again):

Window activate: "Window A" and the active window is "Window B"

and Qt still thinks that A is the active Window (presumably because that was 
the last window explicitly activated by Qt itself).

Maybe Cocoa has two "signals" (hooks, callbacks, delegate methods, ...): 
"aboutToActivate" and "didActivate", and Qt consumes the wrong "event" - or 
even both, but (errorneously) interprets both as "activated"? Just a wild 
guess...

Or Cocoa really sends "multiple" Activated messages, and Qt gets confused?


That somehow reminds me when I tried to get the "full screen" status of windows 
(in order to update a "Enter/Leave Full Screen" menu entry).

Initially I had custom Cocoa (Obj-C) code which added this "native full screen 
arrow" to the top-right of windows (at that time Qt did not support "native 
full screen").

I also had custom Cocoa code which queried the "full screen" state of a given 
window. So whenever my window received a "resize" event (my initial naive 
approach turned out to be wrong here - see below!) I queried the "full screen" 
state with my custom Cocoa code and updated the window entry accordingly (in 
order to react to window state changes initiated by the user by clicking on 
that "native full screen" arrow.

So far so good. Specifically my own "isFullScreen" method returned the expected 
values when queried within a "resize" event (QWidget::resizeEvent).

Qt then provided its own support for that "native full screen" arrow, and I 
decided to completely remove my custom code. Instead I used Qt's own 
QWidget::isFullScreen method again (and QWidget::showFullScreen/showNormal).

However it turned out that Qt's version of "isFullScreen" would sometimes 
return a wrong value: specifically when the "go/leave Full Screen" action was 
triggered "externally", that is by clicking directly on that "full screen 
arrow"! E.g. while the window would start the "go to full screen" animation I 
would get a "resize" event (and really just one, as expected), however 
QWidget::isFullScreen would still return FALSE at this point.

However when I later (after the animation had finished) would query the state 
again (explicitly triggered by e.g. a QPushButton click) QWidget::isFullScreen 
would return the correct value.

It is noteworthy that my implementation - querying QWidget::isFullScreen - 
/did/ work whenever the window state was changed with Qt API itself 
(QWidget::showFullScreen/showNormal)! Then QWidget::isFullScreen returned the 
correct (expected) values, even when being called from within the "resize" 
event. To me it looked like Qt's internal state was "lagging behind" whenever a 
resize event was triggered "from outside" (the "native full screen arrow").

I had created a Qt bug for it (with example code, for the ones curious to know 
how to integrate custom Obj-C++/Cocoa code with Qt):

  https://bugreports.qt-project.org/browse/QTBUG-36718

However it turned out that "I was holding it wrong"! QWidget::isFullScreen is 
(apparently) /not/ supposed to be called from within a "resize" event handler 
(QWidget::resizeEvent)! Instead one has to place it in the (generic) 
QWidget::changeEvent, and then react to QEvent::WindowStateChanged events 
(IIRC)! Then QWidget::isFullScreen returns consistent results.


The above might or might not have anything to do with the "Activated" issue at 
hand, but the observed behaviour just reminded me of my own experience with 
that "full screen" state change issue. Maybe it puts someone in the know about 
Qt internals on the right track (note again however that in my case it turned 
out that the error was on my side - at least I could solve my problem in my own 
application logic).

Cheers,
  Oliver

  




_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to