Dialogs not scaling in certain configurations

You have a laptop that is only 10 DPI? Or did you mean 100?

The "-D" option isn't meant to affect dialogs, as those should already scale properly in virtually cases. The only things -D affects are the things we need to draw manually, like the icons, palette, and score. If other things aren't scaling properly, this is more likely an issue with the high DPI settings in your OS. You can also try experimenting with the environment variable QT_AUTO_SCREEN_SCALE_FACTOR (setting to 1, 0, or unsetting it).

10 DPI is not really a good number is it? Such low-res screens just don't exist

Frequency is the number of users reporting it. What you mean is Reproducibility, which you set to Always

My point is that the -D option is not supposed to have any effect whatsoever on most dialogs. Only the specific things I mentioned: the score view itself, the toolbar icons, the palettes, and other things we draw ourselves. Everything else - the menus, the dialog text, the various standard controls like checkboxes, dropdown menus, etc - all that is handled by your OS and whatever scaling it provides, plus whatever Qt provides.

My guess is you have a bad setting of the scaling options in Windows, but there are so many different possible configurations it's impossible to advise really specifically. But I can say, relevant to the specific symptom you mention of a dialog being so big you can't get to the OK or Cancel buttons - in the properties for the .exe file, try settings the high dpi scaling to "system (enhanced)". That's something I recently saw work on one other system that described a similar symptom. Also try the environment variable setting I mentioned.

Again, it is by design that -D doesn't mess with dialog sizes - it's not supposed to to, as that is normally handled by the system. So you need to look tot he system for solutions if on one that isn't behaving as expected.

It's possible that someday Windows or Qt will improve to the point that workarounds like that aren't needed, or that we will discover yet more workarounds for the unfortunate fact that different systems handle this stuff differently and its virtually impossible to work perfectly on all systems. But for now, we all have to work with things as they are. And that means not trying to make -D do something it wasn't designed to do and would in fact break the option for everyone who depends on it currently to do what it actually does do well on most systems.

To summarize,: you say it's a "blocking" issue, but also that you are not interested in workarounds. Those two statements are incompatible.

Until the world improves - a lot - with respect to how high DPI scaling handled by the OS, device drivers, an libraries like Qt - applications have to do their best to work well on as many systems as possible., And on the very few where it doesn't work out of the box, a workaround might be required. It's the price we all pay when people start building higher DPI displays before providing proper OS support.

It either is a duplicate (but I'm too lazy to search) or we should do better than needing that workaround

Yeah, that's definitely a page with good info for Windows. Most of what we do in the UI is handled for us by Qt. For MuseScore 4, it will doubtless change big time as we migrate much of the UI code to QML and also update from Qt 5.9 to whatever we will end up using, at least 5.15 I assume but possibly 6.something. So we'll have an opportunity to take advantage of the latest and greatest at that point. For now, it's mostly a matter of finding the right bandaids.

I'd just as soon leave this open because it really does describe a kind of different issue from the usual one that is solved by "-D". And hopefully for MuseScore 4 we can do another round of trying to handle as many different configurations automatically as possible.