Details
-
Bug
-
Resolution: Out of scope
-
P3: Somewhat important
-
4.6.3, 4.7.1
-
None
-
* Windows 7 (with the window-opening animation turned off, e.g. by selecting "Windows classic"), to see the jumping layout and the snapshot
* Linux -- no visual jumping, but the eventFilter in the testcase still shows that the black box (child of W2, and parent of the hidden label W3) is resized twice.* Windows 7 (with the window-opening animation turned off, e.g. by selecting "Windows classic"), to see the jumping layout and the snapshot * Linux -- no visual jumping, but the eventFilter in the testcase still shows that the black box (child of W2, and parent of the hidden label W3) is resized twice.
Description
In the constructor of a window W1, the following things are happening:
- show() is called explicitely on a child widget W2 (e.g. due to QStackedWidget::setCurrentIndex(0))
- an indirect child of W2 (let's call it W3) is being hidden
and then the window is shown.
In this situation, the following bug happens: the window first shows with the initial layout (calculated when W3 was still being visible, even though it's indeed hidden) and then the layout is recalculated and everything moves around to the final position.
If painting is requested by the windowing system in between these two layoutings, the window contents will appear to "jump".
The jumping window contents look a bit unprofessional and slow, and annoyed the customer I'm visiting this week, so they asked me to fix it 
I'm attaching here the complete visual testcase for the issue (which uses QStackedWidget, which is the one calling show() on W2), then I'll make a merge request with the much simpler unittest and the suggested fix.