Details
-
Bug
-
Resolution: Fixed
-
P3: Somewhat important
-
6.7.2
-
None
-
Linux/X11, self-built Qt
-
-
7d7be38d9 (dev), 678dccb7a (6.8), 55b69b7f4 (6.7), 98de99f40 (tqtc/lts-6.5)
Description
In the attached testcase, the window is supposed to stay maximized, but merely calling setCentralWidget (or anything else that activates a QLayout) de-maximizes the window.
My analysis: activating a layout calls QWidget::setMinimumSize(), which resizes the window and then tries to restore the maximized flag (but only does so at the QWidget level). The problem is that resizing the window, since commit 99c8ffb9f259760e45618 (the fix for QTBUG-104201), de-maximizes the window at the QWindowsWindow/QXcbWindow level. So merely restoring flags in QWidget isn't enough, the platform window now has the wrong state.
If show() isn't called before showMaximized() then this doesn't happen by chance: showMaximized()'s call to setVisible(true) will do QXcbWindow::setNetWmStateOnUnmappedWindow(WindowMaximized) but QXcbWindow::m_windowState remains 0 so when setMinimumSize calls QXcbWindow::setGeometry which calls QXcbWindow::setWindowState(Qt::WindowNoState) that's a no-op. m_windowState gets updated later in handlePropertyNotifyEvent so no bug in that situation.
It just happens that in my app, I call a factory that returns a widget after calling show() on it, and in that one special case I want to call showMaximized(), so I end up with that call sequence.