[Interest] Confusing activation behavior of floating windows

[Till Oliver Knoll]

> Am 26.11.2014 um 20:17 schrieb John Weeks <john at 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

  




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20141127/e6588cfd/attachment.html>