make application window resizable to smaller width sizes

[SamuelMiller]

Musescore 4 does not have tabbing for displaying multiple scores in the same window. The user now has to have multiple windows open in order to copy/merge parts of various scores together. Currently on Macbook Pro 2012, with a screen resolution of 1280 by 800, MS 4 window size cannot be reduced enough to have two windows side-by-side. It can only be reduced to about 5/6 of the screen's width (see screenshot below). Even hiding the left panel doesn't allow a narrower width. Please consider allowing MS 4 window size to be reduced more (e.g., 640px) so that at least two scores can be displayed simultaneously on at least a standard mid laptop screen size ( e.g., 1280px) to allow easier going back and forth between two scores. (see initial post at https://musescore.org/en/node/335120#comment-1141775)

Narrowest width on Macbook 2012: with the left panel

Without the left panel

[cbjeukendrup]

Yes, the big minimum size of the MuseScore window is an issue currently. The most problematic thing is the top toolbar, which contains a lot of controls and we don't have a way to show them on smaller window sizes yet.

Related reports / potential consequences of this problem:

10965

11083

11627

(just linking them together for our administration 🙂)

[MarcSabatella]

Yes, the big minimum size of the MuseScore window is an issue currently. The most problematic thing is the top toolbar, which contains a lot of controls and we don't have a way to show them on smaller window sizes yet.

What’s strange to me is that the minimum window size is fixed even if I close or undock the toolbars and side panels. There plenty of room to shrink the window but it won’t let me.

[cbjeukendrup]

Currently we have hardcoded the minimum size, hoping that it will always be enough for the dock widgets layout system. If the window size ever becomes less than what's needed by the dock widgets layout system, it will stop working, and you get things like #11627.

It is possible to let the docking system determine its minimum size and use that as the minimum window size. The minimum size would then be adjusted based on which dock widgets you have docked in which places. By strategically closing or undocking panels and toolbars, you could get a quite small window size. I implemented this solution in #12015, but we decided not to merge that because it felt too risky.

[BenWiederhake]

Just ran into this issue. Why not "just" decrease the minimum width?

(A) width cannot be reduced, so there's annoying overlap :-( (B) The toolbars (docks?) can be detached, so there's no issue here. (C) Yeah those thick bars are a separate bug. (D) The score itself can be zoomed out, so there's no issue here either.

I would have guessed the minimum width is just a hardcoded constant that could be reduced? I know, it's never that easy, but it really looks like it should be possible to alleviate this issue.

[cbjeukendrup]

The minimum width is currently indeed hardcoded, and that means that it needs to be sufficient for all situations, so it needs to be large enough to fit when everything is docked.

Why? Once the window becomes smaller than what the docking system needs to properly layout all panels and toolbars according to their respective sizes, the system stops working completely and won't update the size of the panels anymore, with strange consequences, until the window reaches a sufficient size again. This is quite bad and will probably cause even more bug reports than the current situation.

I totally agree though that the situation is not ideal yet...

[bersyl91]

I want to add a use case to this problem: I edit scores with a vertical screen because I work essentially on orchestral scores with 15-25 parts in it and I have to be able to see all parts simultaneously.

Starting with MS4, I'm no longer able to show a full page of score at once, because of the fixed with of the left toolbar.

Can I suggest a feature? It'll be very useful if this palette could be "floating" à la GIMP. This way, one could have the score on a monitor and the palette on another one. The multi-screen configuration is no more exceptional, is it?

[cbjeukendrup]

The palettes (and other vertical and horizontal side panels and toolbars) can be undocked already :) (if everything is working well)

[bersyl91]

Whaow! What a good news! I didn't notice it and it's a huge improvement! Thank you to all!

[EwingKang]

Really hope this issue gets solved since a portrait screen is very common on tablets and is very useful when playing the sheet music.

[runarcn]

Hi, Is it possible to add a toggle in stuff in ie. Preferences > Advanced? I have previously ran MuseScore with Sway (a Wayland tiling compositor) and had MuseScore work in quarter tiling - though here MuseScore is unable to know it's being resized to such a small size and just crops out the parts that are outside of the window (I can provide a screenshot if this is confusing). Other than some elements not being visible/clickable at such small window sizes, I never encountered any of the issues mentioned by @cbjeukendrup, and it worked pretty well for my workflow even if it was somewhat hacky

[cbjeukendrup]

I'm not 100% sure if I understand correctly what you mean. I guess you mean either the following:

1. Sway ignores the (hard-coded) minimum width/height and forces the MuseScore window in a small space
2. This space is even so small that it's not enough for the minimum sizes of the dock widgets
3. KDDockWidgets stops working

or the following:

1. Sway tries to size the MuseScore window so that it fits in that quarter of the screen
2. It fails, because of MuseScore's hardcoded size
3. It places the MuseScore window at the correct position, but it has not the right size, so "sticks out beyond the border of the screen", so to speak.

Which one do you mean?

[runarcn]

I'm not 100% sure if I understand correctly what you mean. I guess you mean either the following:

1. Sway ignores the (hard-coded) minimum width/height and forces the MuseScore window in a small space

2. This space is even so small that it's not enough for the minimum sizes of the dock widgets

3. KDDockWidgets stops working

or the following:

1. Sway tries to size the MuseScore window so that it fits in that quarter of the screen

2. It fails, because of MuseScore's hardcoded size

3. It places the MuseScore window at the correct position, but it has not the right size, so "sticks out beyond the border of the screen", so to speak.

Which one do you mean?

Actually, kinda both. I currently don't have a screen recording setup on Sway so I'll just use screenshots

Here I opened Firefox first, then opened MuseScore and created a Jazz Combo template. Right now the transport sticks out beyond the border, but that is just because MuseScore hasn't been made aware that it's had its size changed yet

Once I do anything in Sway's resize mode, MuseScore adapts without any loss of functionality - the current 50/50 split is not possible on other desktops.

Also works with sidebar open

As I make it even smaller, it starts poking out again but from what I can tell, everything still works

(Toggled concert pitch, wrote a small phrase, added stuff from sidebar, toggled repeat and metronome etc - no issue with anything that is within reach)

Everything that is viewable is still clickable and useable, even in this teeny tiny mode which hopefully noone else will ever use - note input and everything else that can de done with keyboard also seems to work

[runarcn]

Realized that I didn't have Note Input Toolbar enabled here. That starts by hiding stuff as it goes out of bounds before starting to "stick out of the window".