The Advanced Preferences table doesn't allow column width resizing and truncates parameter values on their left.
Open MuseScore Edit > Preferences > Advanced tab. Notice that there are 2 columns, with headings. Notice that the parameter Values are truncated on their left. That is, the first column is too wide and obliterates the first few characters of the Values in the second column. Unlike most tables, the column width doesn't change when one attempts to drag the heading divider to narrow the Preferences column and widen the Values column. Most likely, a parameter of the table description needs to be changed to allow the user to re-size the column widths.
I tested this on Linux Mint 18.3 Cinnamon running MuseScore 3.5.0 RC (dark theme) that was downloaded today, July 22 2020. See attached screenshot. Revision number from About: "OS: Linux Mint 18.3, Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: fb3c202" .
|Screenshot of MuseScore Advanced Preferences from 2020-07-22 21-20-45.png||326.61 KB|
no 3.5 stable release yet
Seems to be a Linux-only problem
Probably also depends on screen resolution, setting of QT_AUTO_SCREEN_SCALE_FACTOR, and "-D". For me on Linux, it looks as expected, but it's like rolling the dice with this stuff soemtimes. I assume the lack of resizability of the columns is something that affects all platforms and would be easily fixable, though.
The lack of resizability is by design: The second column is assigned a fixed width, and the first column is given the rest of the available space.
You seem to have increased your MuseScore UI font size from the default value, which makes the items in the second column not fit quite so nicely in the allocated width anymore.
A fix for this would allow the user to resize the first column and have the second column automatically fill the remaining space, while still allowing the first column's width to automatically expand and contract if the dialog is made wider or narrower. Tricky but doable (I hope).
Could be not a change in font size but in GUI scaling, eg using "-D". Either way, it should still work - UI elements should automatically resize to accommodate this. Most do, but a few don't. Generally, Qt does a decent job of sizing things automatically based on the sizes of the components, but there are some widgets where we are overriding things so this doesn't work right. In those cases we need to multiply the size by guiScaling(). I think that's not the issue here because if it were I'd see it on my system, so you may be right about it being a font issue instead. Still, we need to get sizes like this right. Using a truly fixed width in pixels is never acceptable, so if that's what we're doing here, it needs to be changed somehow.
BTW, another place I notice where sizes seem off is the left-hand panel of Format / Styles - the list of styles. Depending on resolution / fonts / scaling / whatever, this can end up being too narrow for the text within it.
I checked it on my Windows 10 laptop with MuseScore 3.4.2 and it's the same there. That system didn't have nor need any "-D" or QT tweaks. With the default font size (8) the values are not truncated, but when I increase the font to 14 (which is what I had done on my Linux system), then the value for the keyboard layout name is truncated on the left. I use my Linux computer as my living room entertainment system for streaming, so I sit farther away than I do on a laptop and the larger font size allows me to use MuseScore there. Some users with poor vision may choose a larger font even on laptops. For accessibility, if nothing else, the columns should be resizeable by the user. Or maybe just make the values column much wider since the left column is much wider than the contents need. that should be an easy fix until the table can actually allow resizing.
Phew, so not a 3.5 regression ;-)
With the default font size (8) the values are not truncated, but when I increase the font to 14 (which is what I had done on my Linux system), then the value for the keyboard layout name is truncated on the left.
Thanks for confirming. I agree that this should be fixed. I described the way I think the fix should work in my earlier post. What remains is for someone to dive in and actually implement it.