The size of window will overgrow the actual screen size caused by show/hide of child widgets
-
Hi,
I am involved in upgrading a real world application to QT6. The now Qt-6.5.3 app starts in full-screen. However, once child widgets use show/hide, the app grows bigger then the actual screen size.
Maybe this merge is related: https://codereview.qt-project.org/c/qt/qtbase/+/525126
Here some bullets:
- show/hide causes the app be in Qt::WindowNoState although it is/was in Qt::WindowFullScreen. This global state change is maybe not really intuitive to users. Why should show/hide of some child cause the whole app being in another state?
- Setting full-screen again shrinks the app back to the screen size, but this workaround causes to much flickering.
- Our app consist many (!) widgets and much "show/hide" switching is automated based on incoming data.
- Also widgets that are not the current widgets in our QStackedLayout contribute to this overgrowing behavior. My current rather painful debug approach is to comment out widgets and see what happens. Once I have a suspect combination of widgets that may cause the "overgrowing the screen behaviour", I try to work on the size and positioning of the suspects, making slow progress. With progress I mean less overgrowing.
- I finally solved this problem on my laptop after few days of work. However, as usual in real world, in production the app still grows over the screen. From here debug is getting very, very painful.
I assume that also other real world apps that grew over the years will run into this.
Apart from commenting out widgets, how could I debug this?
Thanks for any hints & links to related discussions.
-
Hi,
I am involved in upgrading a real world application to QT6. The now Qt-6.5.3 app starts in full-screen. However, once child widgets use show/hide, the app grows bigger then the actual screen size.
Maybe this merge is related: https://codereview.qt-project.org/c/qt/qtbase/+/525126
Here some bullets:
- show/hide causes the app be in Qt::WindowNoState although it is/was in Qt::WindowFullScreen. This global state change is maybe not really intuitive to users. Why should show/hide of some child cause the whole app being in another state?
- Setting full-screen again shrinks the app back to the screen size, but this workaround causes to much flickering.
- Our app consist many (!) widgets and much "show/hide" switching is automated based on incoming data.
- Also widgets that are not the current widgets in our QStackedLayout contribute to this overgrowing behavior. My current rather painful debug approach is to comment out widgets and see what happens. Once I have a suspect combination of widgets that may cause the "overgrowing the screen behaviour", I try to work on the size and positioning of the suspects, making slow progress. With progress I mean less overgrowing.
- I finally solved this problem on my laptop after few days of work. However, as usual in real world, in production the app still grows over the screen. From here debug is getting very, very painful.
I assume that also other real world apps that grew over the years will run into this.
Apart from commenting out widgets, how could I debug this?
Thanks for any hints & links to related discussions.
@qtfroumusername said in The size of window will overgrow the actual screen size caused by show/hide of child widgets:
how could I debug this?
As always - minimize your code until you can write a proper minimal, compilable example to reproduce the problem. Or try to reproduce it directly with a testcase.
-
@Christian-Ehrlicher Thanks for your answer!
If my/our trial-and-error approach of searching for widget combinations that cause the app oversizing the screen and "thinkering this away" is the right approach, providing a minimal example is orthogonal to the solution path.
Can you confirm that our approach here is the way to go? Are there other tools or paths available?
Also, do you agree that is breaking behavior that potentially affects many real world apps? Less important, I do not understand the rational behind: with show/hide of "some random" widget the app exits the fullscreen state. Why is this even related?
Before me and my team continue the described expensive path, I just want to doublecheck we spend our time in the right corner.
-
If something is too big for the screen, put it into a QScrollArea. This might be the fastest to debug. If all child widgets are within their own respective QScrollArea, you can then on the target machine figure out which ones show scroll bars. These are then too large for the screen. (If you don't want to rearrange/redesign the child widgets this is also your only solution in the long run.)
Concerning stacked widgets: if you have many of these, it might be helpful to only create the widget when it is made the current widget for the first time. Creating many widgets which are not visible at all might significantly slow down startup of the application.
-
@SimonSchroeder Thanks for the +1 that we are looing into the right direction. I will take a look into creating widgets when they are required; however, changing lifetime is not trivial in this app. Also, the startup time of the app is OK and not a blocker in any sense in our our use case.
Another promising tweak is to address the oversizing for a screen resolution smaller then the smallest target, just if others are running into the same problem.
Is there any possibility of switch of the described behaviour at Qt's side? Still, I see the possibility that this is a bug in Qt6 and not a feature.
It would be great if the Qt team could at least get a +1 for looking into this if some moderator is reading this.
-
@hskoglund Thanks, I did play with this. However, we have a "toggle" button among fullscreen/maximazied/normal(no state since QT6) that needs to be available to users. I think this undermines this workaround. Ill have another look.
-
@hskoglund Thanks, I did play with this. However, we have a "toggle" button among fullscreen/maximazied/normal(no state since QT6) that needs to be available to users. I think this undermines this workaround. Ill have another look.
On what OS/platform your app is used?
Is Linux with a Wayland windowing system involved by any chance?
There are some known bugs and unwanted behavior when it comes to moving and resizing windows/widgets on Wayland platforms -
@Pl45m4 Sure, forgot to mention the operating system. In our case we are on Windows, mainly Windows 11 Enterprise and Pro. No Linux involved for the GUI part yet.
Still, it smells like an unwanted breaking change made by Qt; maybe related to the merge I linked in my first post.
-
Stumbling again here it looks like a simple setMinimumSize(size of the screen) on the main Widget inheriting QMainWindow did the trick. With trick I do mean, that the window even stopped leaving Qt::WindowFullScreen to Qt::WindowNoState completely onShow()/setVisibility(true) of some random child.
Going down the road and checking where the sum of all widgets overgrows the screen would be the right thing to do, but in larger lagacy apps that need to be backwards compatible to small 5:4 resolutions this is near to impossible. The actual size of the widgets depends on real world data this is near to impossible to get/simulate.
