I don't see this though in the latest build (on Windows 7):
OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: a18e190
It isn't and and the same meanwhile also with an actual nightly. But as mentioned above, the appearance was/is correct with a nightly in time of my first report.
The supposed "fix" doesn't do anything useful, and I do not think it ever did. If you set your font size to what it was in the "correct" screenshot, everything should fit the way it is supposed to. The minimum height of the Preferences window is based on a font size that is lower than what you are currently using. By the way, are you able to make the window taller by resizing it from the top?
Yep, you're right, the reason seems to be the default font. The default font face in the beta and last nightly is here "noto sans". When I increase the height of the style window the fields appears correct.
If I switch to "sans serif" it appears correct without having to resize the style window. So it seems the issue is the default font face?
When I revert to factory settings "noto sans" is the default font with the appearance in the style window as reported. Only after resizing the window by using this font or changing the the font face to "sans serif" without it's necessary to resize the style window it appears correct. Checked it several times, at moment can't imagine another reason.
I don't check each nightly, but attached the difference of the default settings and mentioned appearance - font face, font size - between revision: 2014923 and revision: c36c7eb.
In addition, the list of pages for this dialog - the list widget on the right side of the dialog - is not wide enough. I was trying to debug that the other day but couldn't figure out if it was a scaling issue or size policy issue.
This is what I see after factory reset, so all default settings:
I actually use "-D 166" to scale things for my (high DPI) display, so 100% zoom really is 100%, the palettes are life size, etc. But I get the same results in this dialog within that.
Comments
I don't see this though in the latest build (on Windows 7):
![foo.png]( "foo.png")
OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: a18e190
and indeed the commit after the one you used changes exactly that dialog, so I'll mark this issue fixed
Yes, it appears correct in the latest nightly (d5e192b), but it doesn't in the AppImage prepared as alpha version.
Screen size problem?
This's probably due to the new option for bracket configuration which limits the space of other options. I'll take a look.
See https://github.com/musescore/MuseScore/pull/6051.
I'm not familiar with code, but FWIW attached the difference of appearance between the alpha of 3.5.0 an a nightly for me.
Fixed in branch 3.x, commit 2c5d5d851b
_fix #304834: settings field for mulitmeasure rests is too small
currentIndexproperty_Fixed in branch 3.x, commit 9345faca7f
_Merge pull request #6051 from Howard-C/style-dialogue
[Regression] fix #304834: settings field for multimeasure rests is too small_
needed for master too
In reply to needed for master too by Jojo-Schmitz
I think the Styles dialogue will be redesigned in 4.0, based on the frequency of @Tantacrul complaining about it? :-)
It isn't yet though
Shouldn't it also be merged in the 3.5alpha branch to check a nightly build, or does 3.x mean that it's fixed in the final 3.5 release?
The latter, the 3.x branch will be used to branch off 3.5 Beta
It isn't still fixed in the beta.
It should though, the above mentioned fix is in.
It isn't and and the same meanwhile also with an actual nightly. But as mentioned above, the appearance was/is correct with a nightly in time of my first report.
To compare attached the screenshots.
It's very weird. It's almost a nightmare trying every size policy and they all look like the same. Only more reason to move to QML, I guess.
The supposed "fix" doesn't do anything useful, and I do not think it ever did. If you set your font size to what it was in the "correct" screenshot, everything should fit the way it is supposed to. The minimum height of the Preferences window is based on a font size that is lower than what you are currently using. By the way, are you able to make the window taller by resizing it from the top?
Yep, you're right, the reason seems to be the default font. The default font face in the beta and last nightly is here "noto sans". When I increase the height of the style window the fields appears correct.
If I switch to "sans serif" it appears correct without having to resize the style window. So it seems the issue is the default font face?
Are you sure nothing changed in your own system settings that would have caused MuseScore to select this font upon startup?
When I revert to factory settings "noto sans" is the default font with the appearance in the style window as reported. Only after resizing the window by using this font or changing the the font face to "sans serif" without it's necessary to resize the style window it appears correct. Checked it several times, at moment can't imagine another reason.
Is this the case for the older nightly as well as the more recent versions?
I don't check each nightly, but attached the difference of the default settings and mentioned appearance - font face, font size - between revision: 2014923 and revision: c36c7eb.
That default font, or rather the method to find it, indeed changed for 3.5, at least for Windows
See #302114: Wrong default GUI font under Windows
FWIW I still see the same on Linux. And also see #307427: Create Multibar Rests and Chord Symbols Positioning settings UI squashed
In addition, the list of pages for this dialog - the list widget on the right side of the dialog - is not wide enough. I was trying to debug that the other day but couldn't figure out if it was a scaling issue or size policy issue.
This is what I see after factory reset, so all default settings:
I actually use "-D 166" to scale things for my (high DPI) display, so 100% zoom really is 100%, the palettes are life size, etc. But I get the same results in this dialog within that.
Came up again in https://musescore.org/en/node/309932, including another pages of that dialog with the same problem
See https://github.com/musescore/MuseScore/pull/6534
Fixed in branch 3.x, commit bc02351cf5
fix #304834: https://musescore.org/en/node/304834
If stack content is too big then we will adjust stack size
Automatically closed -- issue fixed for 2 weeks with no activity.