Explanation of palette size changes in MuseScore 3.3.4

Some users may be noticing that your palettes have become larger or smaller in MuseScore 3.3.4 compared to previous versions. I would like to explain what is going on so that people can understand why you are seeing a change, and how to customize the size

First, the TLDR: prior to 3.3.4 people saw wildly different palette sizes depending on their monitor resolution, but as of 3.3.4 everyone should be seeing "close" to the same size - meaning that size might be bigger or smaller than what you had become accustomed to. You can now customize your palette size with Edit / Preferences / Advanced / paletteScale.

Now, here's the full story:

In MuseScore 2, palettes were always the same physical size for everyone, regardless of monitor resolution. In particular, if you opened the key signatures palette and compared the size of the staves there with the size of the staves in the default empty score, they would match exactly. I call this "life-sized". Other palettes were deliberately scaled smaller or larger to achieve some visual consistency within the palette despite the symbols themselves naturally being different sizes. You can see and customize this scaling in Palette Properties. But the point is, in MuseScore 2.0, a scaling value of 1.0 always meant life-sized

When MuseScore 3 came out, the code that handled the automatic "life-sizing" of the palettes was (inadvertently? mistakenly? ill-advisedly?) removed, making the size of the palettes dependent on your monitor resolution. So for the past year, everyone has been seeing different palette sizes. Sometimes wildly different. People with "normal" monitors would not have been affected - they have been seeing the key signature palette "life-sized" all along, and other palettes scaled as per Palette Properties. However, people with low-resolution monitors or older connections (eg, TV sets connected via VGA) have been seeing larger palettes. And people with high-resolution monitors would be seeing smaller ones.

That's a bug, pure and simple. Because this is a pervasive issue across many applications that were written prior to the advent of high-resolution monitors (or by people who don't know how to adapt their code properly), most OS's provide some sort of control to try to work around these problems. But on some high DPI systems without the OS-provided assist, the palettes were really tiny. On my Chromebook/Linux system for example, palettes were barely half the size they were designed to be, and the OS option to scale things for me results in extremely bad rendering.

So, for 3.3.4, we reinstated the code designed to make the palettes life-sized for everyone again (the palette redesign undertaken for 3.3 actually made this easier). But realistically, we know that many people these days have high-resolution monitors these days and have become accustomed to the palettes being smaller than they were actually designed to be. We didn't want to suddenly shock people by forcing their palettes larger than they have become accustomed to, even if it was just a bug they were ever that small. Therefore, we decided to put limits on how much we increased the size of palettes for people with high-resolution monitors, and we also decided to provide a preference to customize the size of your palettes as a whole, without the need to resort to scaling each palette individually in Palette Properties.

The compromise we came up with is this:

People with normal monitors were seeing life-sized palettes before, and they continue to see life-sized palettes with 3.3.4. People with low-resolution monitors were seeing larger-than-life palettes before, now they are seeing life-sized. So, smaller than they are used to, but we don't expect anyone will complain about this, since life-sized is pretty big already).

People with high-resolution monitors were seeing smaller-than-life palettes before. While we could have made them all life-sized (and thus bigger than they are used to), what we did instead is leave these alone unless that results in palettes being be smaller than 75% of life-sized, in which case we bumped them up to 75%. So, people with high-resolution monitors that had palettes smaller than 75% of life-sized will now be seeing this bumped up to 75%.

The bottom line is that everyone should now be seeing palettes within the 75%-100% range (previously the range could have been more like 30%-150%). If you don't like the size you ended up with, you can increase or decrease it using Edit / Preferences / Advanced / paletteScale. Note that 1.0 here doesn't mean life-sized, it means whatever the default is on your particular system.

I know this is a lot of information; TMI for most people I'm sure. But given the number of questions and issues that have come up over the years regarding the size of the UI on different monitors, I wanted a full explanation we can point people to.

I should mention that only palettes (including the Master Palette) are affected by this change. Size of toolbar icons, fonts in dialogs, the score itself - these things are already either scaled correctly according to your monitor resolution in most cases. And for those systems where this doesn't work right, there are already overrides for that (the "-D" command-line option to specify DPI, preferences for font and icon sizes, also a handful of little-known Qt-specific environment variables that can be relevant). But none of those settings affected the palettes.