[Qt-interest] setUnifiedTitleAndToolBarOnMac and Cocoa Qt cause problems

[Nils Jeisecke]

Hi!

This is a problem with the frameStruts. They do not reflect the height 
of the unified toolbar (which is part of the Window Title) until
the window is shown.

Ugly workaround:

#ifdef QT_MAC_USE_COCOA
     bool workaround = !mainWindow->isVisible();
     if (workaround) {
       // make "invisible"
       mainWindow->setWindowOpacity(0);
       // let Qt update its frameStruts
       mainWindow->show();
     }
#endif

     // restore size
     mainWindow->resize(currentItem->d_func()->mwSize);

#ifdef QT_MAC_USE_COCOA
     if (workaround) {
       // move window
       mainWindow->move(mainWindowPos);
       // make window "visible"
       mainWindow->setWindowOpacity(1);
     }
#endif

This seems to work so far...

Nils

Am 22.07.2009 22:05 Uhr, schrieb Israel Brewster:
> Ok found a work-around of sorts: it appears that this error only happens
> if the window is sized and positioned before show() is called. This is
> actually mentioned in the docs in reference to X11 windows:
> (http://doc.trolltech.com/4.5/geometry.html) where it says:
>> "...A workaround is to call setGeometry() after show()..."
>
> HOWEVER, it goes on to say:
>> "...A safer solution is to store both pos() and size() and to restore
>> the geometry using QWidget::resize() and move() BEFORE calling
>> show()...This method works on Windows, MAC OS X, and most X11 window
>> managers" [emphasis added].
>
> As my test cases show, however, this doesn't work under the specified
> conditions (Cocoa and setUnifiedTitleAndToolBarOnMac). Under these
> conditions, from what I have been able to tell, the ONLY way to
> successfully restore the size of the window to to call either
> setGeometry or resize() and move() AFTER calling show(). This,
> unfortunately, has all the disadvantages listed in the above referenced
> documentation. saveGeometry() and restoreGeometry() appear to fail
> regardless of when called (before or after show()).
>
> As a somewhat interesting side note, the degree of failure does vary
> depending on which method is used. For example, with a window that
> initially has a height of 454, when restored using setGeometry() it has
> a height of 433 - a decrease of 21. However, when that same 454 window
> is restored using resize(), it ends up with a height of 412 - an
> additional decrease of 21 over the change with setGeometry, or 42 total.
> Not sure why 21 is the magic number here, or why resize() makes the
> window smaller than setGeometry().
>