Format > Style window is too large

• Sep 20, 2018 - 20:29
Reported version
P1 - High
Graphical (UI)
S3 - Major
PR created

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 26ad655

For MS 2.2: The minimum dimensions of the Style window are 21 x 17 cm.
For MS 3.0.0: The minimum dimensions of the Style window are 22.5 x 21cm.

Clearly, the Style window in 3.0.0 is too large. The width has increased by 1.5 cm, the height by 4 cm, over MS 2.2! The style window must be small enough to allow the user a clear view of the score when making on-the-fly adjustments such as those from the "Page" dialog.

Please allow the user to reduce the Style window even further.


I fully agere that something needs to be done about the size.
Though most of the options use only a small part of the screen, there are a few that take up the whole space. Also, because the list og options cannot be scrolled, the height seems to have been set based on the number of options.
Of course it must be possible to allow to make the window smaller, but it will mean that some fields will dissapear, and you may have to rezise to see the entry fields you wish to use.

Have you though about how this could be solved?

Severity S4 - Minor S3 - Major
Regression No
Workaround No

I don't know about others, but with the second beta I can't even see the buttons on the window to click OK, Cancel or whatever the other button says.

In reply to by Jojo-Schmitz

Currently at 1440x900, but changing resolution (e.g 800x600) in Windows does not change the size of the dialog.

The dialogue seems to open at it's maximu height. Suggest it could be changed to minimum, which is large enough to show all the different pages.

My resolution is 1024 x 768. If I remember correctly, my scree is 21" diagonal. It's at least close to that.

Both the "Header, footer" and the "System" pages use the entire window. I would suggest that on header,footer, the metatag boxes be made smaller, like there are in version 2. In the "System" page put the dividers options next to each other. On this page it's also possible to put Font Style and Align starting on the same line. They are spread out to the point the buttons seem rather random than related.

Images? What are the new sizes? Seems it still won't fit x600, but would x768, right? So 1024x768 might be the new minimum screen size we can support

If my PR gets merged, we can conceivably remove almost all of the font controls from the individual pages of this dialog, thus reducing height requirements for most of them. Not sure if that would be enough to reduce it overall below 600px; probably not. But it would probably simplify make the task of rearranging those few pages that exceed this.

Reducing the height will mean that the user will have to scroll the Pagelist to reach the last pages. I dont particularly like that.

It's unclear to me what objective you have about the size. If I reduce the screen setting from 1440x900 - which I normally use - to 1024x768, the height increases from 16 to 18,5 cm, but that only changes the footprint, and I cant see how that relates to a recommendation for say min. x768, or indeed to the height setting in Qt designer.

Status PR created fixed

Fixed in branch master, commit 0c99e1f4b6

Fix #276404: Format->Style too large

Format changes to System and Tuplet pages to make sizes more even.
Size constraints and policies changed to open dialogue at minimum size.
Toool button added to hide/show pagelist.

In reply to by Jojo-Schmitz

Two of my laptops are also 1024x768. One is too old for MuseScore, the other belongs to my employer, not me.

I also have another Linux laptop which can run MuseScore. It has 1024x600. I’d expect it to work there. (Although I can use RDP from the old 1024x768 laptop to access MS running on the EeePC. But 1000x750 (a little less due to window decorations) is an absolute must.)

We should stop discussing the required size.
(Even though the title of this topic is "Style window is too large".)

The problem is NOT the number of pixels required.
The ploblem is that some windows are neither resizable nor scrollable.

cf."Palettes" panel (as a Good Example)

We can handle many settings even if the main window is small because "Palettes" panel is scrollable.

Attachment Size
PalletesPanelOK.png 99.69 KB

I have a solution for this that is currently a bit raw, but it might allow for some refinement. The solution is to put scroll bars on the right hand pane in the edit style dialog (in the code that's the pageStack variable/widget). So far I have a basic implementation via just two lines of code:

QScrollArea* scrollArea = new QScrollArea(splitter);

The dialog is very wide and tall, and this pageStack seems to size all of its child pages to the same size as the largest page in the stack. I currently don't know if there's a way to get the scrolling to be more correct for each page, but for now these two lines of code solve the problem.

I will create a PR for this very soon, probably tomorrow at the latest. I wanted to notify here of my pending solution, to see if there's any feedback first.

Status active PR created

I have found a way to solve the biggest problem with the scroll bars:
- If your screen is big enough to not need scrolling, they appear anyway.
That removes my main misgiving about merging this solution. The PR is here:
It could still use some refinement, but I'll leave that for another time, or for someone else.

Note that this checks the size of the "primary screen". For users with multiple monitors, this assumes that the dialog displays on the primary monitor. That may or may not be the case. But it seems that this is more likely an issue for single monitor setups. Let me know if you see an issue with this and I'll see if there's a way to know on which monitor the dialog is about to display. I don't see anything about that in some basic searches and docs. The other possibility is to force this dialog to display on the primary monitor. I have two monitors and sometimes dialogs and message boxes display on the 2nd monitor. I don't know the logic for that, but it happens.

I tested it by setting my primary monitor's resolution to 800x600. The edit style dialog height is 660px, at least for me on Ubuntu. This code displays the scroll bars in that resolution and not in my normal 1920x1080. I hope it works well for others :-)

I worry that the dialog might still be too large for the scroll bars to show. I'm adding code to set the dialog's max width and height to the screen width and height. This is messy to test with my 2 monitor setup. At 800x600 part of the dialog defaulted to being on the 2nd monitor, but the dialog wasn't centered on my primary monitor. I'll leave the centering until later, but for now I'm eliminating the possibility of the dialog being larger than the primary screen. I'm amending the PR now.

It turns out that I must set a fixed size for the dialog, as the setMaximumSize() function is not working in this situation. That's not a big deal.
But in spite of the fact that the dialog is set to 800x600, verified in the code, it's still slightly larger than my screen (now I'm testing in Windows, which seems a bit better at 800x600 than Ubuntu, which got a bit freaked out with the 2 monitors). I have pushed the changes to the PR. I want to wait until others who are actually experiencing this problem in their normal setups can test it and see how it looks for them. It's unfortunate that it has to be so disconnected, but I don't trust any further changes I could make to reduce the size of the dialog.
As it stands, this should at least be an improvement for you all. You should be able to access all the fields in the dialog once this PR is merged.

Why is this dialog not user-sizable?
If there is no good reason, then I can enable that too, which will probably help too. Or I can enable it only when the scrolling is enabled. Any thoughts?

OK, I finally got the size right. Sorry for all the posts, but I think I have it figured out and then something occurs to me later. Thankfully this occurrence solved the problem.

1) The title bar is not included in the QDialog's height, you must get the frameGeometry rect.
2) The title bar doesn't exist at the time the constructor is called, you must wait until the showEvent fires.
So the code is now in showEvent() and it takes the title bar and window borders into account when setting the dialog box size. The dialog now fits in Windows 10 at 800x600, which is the lowest resolution my Windows 10 offers me.

I feel much better about this solution now. Sometimes it takes a while to understand how Qt does a specific thing.

I was incorrect: the dialog box is already user-sizable, but only bigger, not smaller. The latest code in the PR handles this. It also handles restoring an even smaller user-configured size.

On a separate note: I think the best solution to all of this is to make this right hand pane always scrollable. QScrollArea is smart about hiding the scroll bars when they are not needed. The only issue is that the dialog is substantially wider than it appears by default. The default width of 912px is not wide enough to display all of the fields in the Page page, for example. The horizontal scrollbar hides when the dialog gets to 1100px wide. There are some very long/wide labels in the dialog. I think there are even longer/wider labels in some of the translations. But if this is the case, then the scrollbars are a good thing, as they allow even users on large screens to access the fields without resizing the window.

I now have two PRs that fix this issue and another set of issues with this dialog's size.
IMO, the layout of this dialog is too fancy, too funky. It tries to do too much and thus makes it difficult to do the simple things.

For example: The pageList (leftmost list of style categories) is both sizable and hidable. It should just be hidable.
When you hide the list, it makes the whole dialog smaller (except when your screen is small, I fixed that in this issue's PR). It should always act like this PR and simply hide the list. The only reason to hide the list is to provide more space on the screen for the fields. The current code goes out of its way to do the opposite. In the process it causes all kinds of complications that would be best avoided.
The pageList should simply be a fixed width, wide enough to fit the widest list item in the current font. Then you can hide it if you need more room. That's one fix that would simplify and improve this dialog. I'm not sure how to implement that, and I've got too many other things to do, but I wanted to make note of it here.