[MU4 Issue] Oversized status bar after switching between fullscreen and windowed

[SnyBr]

This:

To reproduce:

1. Directly after MuseScore startup, create a new score or open an existing score.
2. Press F11 to enter fullscreen
3. Press F11 again to exit fullscreen. The now oversized status bar also cannot be dragged back down to the bottom of the screen.

I use an old 4:3 monitor on 1024x768 resolution. Tested on MuseScoreNightly-202205130439-master-001f7a6-x86_64.

[SnyBr]

I couldn't reproduce this on a 16:9 display, so it seems related to the screen aspect ratio.

[cbjeukendrup]

I have been able to reproduce this on a virtual Windows machine running in a small window (i.e. the "screen" of the Windows machine is a resizable macOS window). The problem occurs when the width of the screen is smaller than the minimum width of the MuseScore window. The minimum width is currently 1150px (that's huge in my opinion), so indeed that will be problematic on a 1024x768 display.

[GabeS573]

I was not able to reproduce this.

Screen aspect ratio: 16:9 (1920x1080)
OS: Win11
MU4 version: Private Alpha

[GabeS573]

The problem occurs when the width of the screen is smaller than the minimum width of the MuseScore window.

If what @cbjeukendrup suggested is true, then this is also related to #10965

[Tantacrul]

We do need to reduce that minimum size. It is much too big. @cbjeukendrup - I imagine it's a really quick fix to set it to 1020 or even 980 and we'll see how it holds up?

[cbjeukendrup]

I'll experiment a bit with it, but I think there is a reason that the value is so high currently, so that will need to be fixed before we can lower it. That may not be entirely trivial.

[Tantacrul]

I suspect the reason was because there was a lot of clashing UI before. Most likely, it was done to limit the likelihood of the Note Input bar breaking when there are too many objects added to it. However, if I'm right, we can at least shrink it a bit...

(Incidentally, we do need a proper responsive solution for the top bar in 4.1)

[henkdegroot]

Just to confirm, I was also able to reproduce on 1024x768 using my windows 10 machine.

[cbjeukendrup]

As I just said in #10965, the core of the problem is the following. If the window reaches a size that is smaller than needed by the dock widgets system to realize the specified minimum widths for toolbars and panels, the dock widgets layout manager completely stops working, which results in behaviour like in this issue.
So, the reason that we set such a big minimum width, is to prevent that the window becomes smaller than the dock widgets layout manager can handle. But apparently, when going full screen, that situation can still occur.
I found experimentally that the minimum required width is circa 1000px:

If we want allow the window to be smaller, we will have to build some special behaviour for that.

[Tantacrul]

As small as we can go without breaking anything, I suppose :)

[jeetee]

There are plenty of laptops out there with 1600x900 so a 1000px minimum height seems rather large imho.
I'm also unsure how/if the windows scaling factor has any effect on this, where on many laptops this results in even less available logical pixels. Even on my 15" 1080p one, they chose a default scaling of 125%, which leaves only 864 height px, taskbar not yet subtracted (I have reset that to 100% because I'm not blind, but you get the gist).

If going below 1000px minheight means delaying Alpha, then I'd go with that big minimal value as a start. We can always then schedule the work if/when the complaints come in.

EDIT: I just now realized (what sleep can do for you!) that this is about minimal width and not height... so slightly ignore this comment except for taking into account that scaling mode of Windows messes up the available pixelcount.

[GabeS573]

Just to point out, even if your laptop screen is bigger than the 1000px minimum width, the minimum width still gets in the way if you try to multitask/split-screen (which is part of the issue I logged, #10965.)