Format > Style window is too large

I agree. I thought about putting this as a feature request myself.

Came up again https://musescore.org/en/node/276413

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?

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.

at what screen size?

I see the same at screen size 39 cm (i.e 15").
Height of dialogue is some 21 cm. See attached screenshot.

I'm asking screen resolution, x-pixels * y-pixels

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

EDIT.
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.

1024x768@21" is a very low setting. I'm using 1600x1200@20"

It makes most everything a comfortable size for me. This shouldn't matter. The problem is that the window is now much larger, and with not reason, than it was in version 2.x.

..and regardless of these settings, it should still be ensured that the OK and Cancel buttons are displayed within the available screen space.

At least all dialogs should stay within the limits outlined in the https://musescore.org/en/download#Minimum-requirements (or those need to get adjusted, which they need to anyhow, MuseScore 3.0 for Windows requires a 64bit CPU and Windows version)
Current documented limit (suitable for Chromebooks IIRC): 1024x600 pixel resolution

I am working on changes to editstyle.ui, that adress some og the problems.
@Jojo-Schmitz could you maybe try to run with -F, and make a screenshot. Just to make sure if it behaves the same in your environment, as it does in mine.

I've just removed the correspoiding line from my MuseScore3development.ini and got
1348x935 pixel

and 819x801 pixel

Thanks a lot. It's as expected, so i'll continue with the changes, I working on.

Links to:
https://github.com/musescore/MuseScore/pull/4165

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

Images? - Asume you are talking screenshots.

Pagelist open:

Pagelist closed:

System page:

Lyrics page:

Tuplets page:

Size according to Qt is 910x660.

If my PR https://github.com/musescore/MuseScore/pull/4159 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.

I'm talking about the minimum requirements, as outlined on the download page, down at the bottom

Thanks Jojo. Now I've got it.
I guess you are right that x786 is minimum.
Fitting the Style into 1024x600 would seem to require a complete re-design.

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.

Fixed in branch master, commit ada975681d

Merge pull request #4165 from neGjodsbol/Style

Fix #276404: Format->Style too large

Removing font settings could maybe be combined with adding the still missing reset buttons.
See https://musescore.org/en/node/278535

came up again in #279082: Format > Style dialog too large, too large for 1920x1080 13" 150%

Everything is too big on my 15" laptop Full HD with 150% scaling. Not the case to fix at all or very low priority.

also at 100%?

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.

came up again in https://musescore.org/en/node/282649#comment-901686
Not the case in MuseScore 2 -> Regression

Came up again in https://musescore.org/en/node/285803#comment-902649

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);
scrollArea->setWidget(pageStack);

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.

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:
https://github.com/musescore/MuseScore/pull/4929
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 spent some time trying to implement the QScrollArea always on, and ran into a bunch of difficulties. Too many interacting, auto-resizing parts. I don't know enough about Qt layouts, and I'm not sure I want to learn.

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.

Fixed in branch master, commit c01c263eb3

FIX #276404 edit style dialog screen overflow

Fixed in branch master, commit 60ff1ebc93

_Merge pull request #4929 from sidewayss/scrollEditStyle

FIX #276404 edit style dialog screen overflow_

For those who experienced this issue, it would be great if you could build the latest master and test it prior to the 3.1 release. ...or use the latest nightly build.
Thanks.

Here is a link to the latest nightly build:
https://ftp.osuosl.org/pub/musescore-nightlies/windows/MuseScoreNightly…

See #288489: Style dialog shouldn't resize when left pane is hidden

or see this PR, which lists 3 issues related to showing/hiding the page list:
https://github.com/musescore/MuseScore/pull/4938

Which is #287863: editstyle.ui - Hiding left-hand list (pageList) causes width to be fixed, not sizable, #287864: editstyle.ui - Hiding left-hand list then showing it: size too small and #287923: editstyle.ui - Hiding or showing left-hand list (pageList) reverts to default size

Automatically closed -- issue fixed for 2 weeks with no activity.