Qt window fixes

[johnzhou721]

List of fixes:

1. Use container resize to do relayout instead of window resize to do layout; the latter gets the first layout before any resize happens wrong because of the addition of the menubar. I've had to still keep on_resize with window resize, though, else some window state tests fail because when container gets resized, the window size isn't up-to-date yet for some reason. This implies that on_resize effectively may run after the refresh unlike before on other platforms, but that may be the cleanest way to solve things in the codebase (i.e. rather than refresh on menubar insert, refresh on toolbar insert etc.)
2. Slightly rework window state transitions to always go through NORMAL as an intermeditae step when apppropraite -- I started observing local failures on window state testbed tests, becauses non-NORMALed transitions doesn't work consistently. Since the list of non-NORMALed transitions that does not work may change (as it's already did), I've just used going through normal every time instead of specific cases.
3. Minor fixes in tests.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

This all seems to make sense; one question about a change to the image size probe.

[freakboy3742]

This seems like a significant change - it's guessing about the window, rather than using a screen that has been explicitly provided as an argument. What's the significance here?

[johnzhou721]

@freakboy3742 Looking back I can see how this gets unreliable... however, the documentation of QScreen. devicePixelRatio says that that function should not be used when there is a window to target; because QScreen. devicePixelRatio can give wrong values under Wayland with fractional scaling, so we have to have a window on that screen to assert.

So should we try to go through our windows one by one to see if one of them belongs to the screen and if none of them does, just do nothing? That'd be more reliable.

[freakboy3742]

My suggestion would be to avoid the temptation to guess.

If the QT backend should operate on the window rather than the screen... provide that detail to the assertion. Add a window argument, and explicitly provide the window as context. Other backends may not need that detail; but if they have it, they can use it.

AFAICT the main reason the existing method accepts screen rather than window is that you can take a screenshot of a screen and it doesn't necessarily have a window on it. So - it seems to me that if you don't provide a window, the screen's DPI is the one that should be used.

[johnzhou721]

@freakboy3742

But if you set display settings resolution to 175%, https://doc.qt.io/qt-6/qscreen.html#devicePixelRatio-prop actually returns 2, so the function gives wrong values. Would an approach like "window provided > that window used, screen provided > look for windows on that screen, if all else then assert within a generic range, say 50% to 300%" be okay?

[freakboy3742]

... how does that relate to anything I said?

[johnzhou721]

@freakboy3742 I have "window provided > that window used" which was what you said.

To be completely clear about this, accounting for the fact that I have previously failed to provide enough context:

• I was agreeing with you mostly about explicitly having a window context.
• But for this part:

AFAICT the main reason the existing method accepts screen rather than window is that you can take a screenshot of a screen and it doesn't necessarily have a window on it. So - it seems to me that if you don't provide a window, the screen's DPI is the one that should be used.

... the screen's DPI may be wrong under Wayland with fractional scaling, so we must have a window to get the ratio. The key here is that we must have a window to target, at least from my testing.

So this yields the logic I mentioned:

• If window provided, use the ratio of that window
• Else, if screen provided, find windows that are on that screen, and if available, use the ratio for that window
• If all else fails, assert that using a reasonable scale, it is possible to produce the resolution of the actual image.