reduce size of inspector panel

• Dec 18, 2019 - 21:15

Because I moved my score from a large auxiliary screen to a laptop screen, I lost the top and bottom margins of the inspector panel. I can move the score back to the large screen, but I am stuck with the panel on the laptop screen. Anything I can do besides deleting and downloading?

Comments

• Dec 19, 2019 - 01:12

Many thanks for your response. I am not very computer literate and should have asked one of my children how to write the command line instruction. After many futile attempts, I bit the bullet, went to help >Revert to factory settings. Everything is cool now. Need to readjust preferred settings. A minor problem. Musescore is a wonderful program.

Reply

• Dec 19, 2019 - 17:29

Not quite sure what you mean. The Inspector by default takes up the heigh of the window, with scroll bars as needed. Did you uncock the Inspector and now you want to change its size? Just drag the window handles if so. Or if you mean the size of the text within it, that should be the same as all other text controlled by the setting in Edit / Preferences. If that doesn't help, can you describe your problem in more detail, and attach a screenshot?

Reply

• Dec 19, 2019 - 18:15

I'm referring to the size and spacing of the GUI controls within the Inspector. I was hoping to be able to shrink everything so that I can fit the whole Inspector in less vertical space so that I don't have to scroll up and down when there are a lot of properties. Decreasing the font size decreases the size of the text, but barely changes the height of the Inspector once you go below a certain point size (9 or so) because the controls themselves appear to have minimum sizes and spacing.

I'm using a “4k” (3,840×2,160-pixel) display under Windows 10. Under my Windows Display settings I have the scaling set to “150% (recommended)”, which results in a nominal resolution of 144 DPI.

I'm able to get everything to become proportionately smaller in MuseScore (including everything in the Inspector) by changing my Windows Display settings scaling to, say, “100%” (i.e., 96 DPI). But I don't want to do that, as it affects the whole system.

The --monitor-resolution MuseScore command-line parameter is documented to “Specify monitor resolution (override autodetection)”. I would have expected MuseScore3.exe --monitor-resolution 96 to produce the same results as setting the scaling to “100%” at the OS level, but alas, it doesn't. Instead, makes the toolbars and score appear larger (bizarrely — I would expect them to be smaller), and it doesn't effect any of the panels at all, including the Inspector. (I took before-and-after screen shots to be sure, and the Inspector is pixel-for-pixel identical.)

Similar results with --gui-scaling 0.67: The toolbars decrease in size, but the Inspector panel is completely unaffected.

I'm hesitant to post huge screen shots as this should be really easy to reproduce. But if you have trouble reproducing it on your end, I can post some for you.

Reply

• Dec 19, 2019 - 18:42

I'd have to see a screenshot to understand if you are seeing something unusual. On most displays, the Inspector should fit the height of the monitor easily for most element types, but a few, like notes and lines, have so many controls they aren't going to be able to fit readably.

Lying about your monitor resolution - telling MuseScore you have higher resolution that you do - will certainly cause things to scale incorrectly. If you tell MuseScore you have a display that is, for example, 500 DPI, then by god, it's going to put 500 pixels up on the screen every time it want to make something an inch big, and if your monitor is actually only 250 DPI, those 500 pixels will take up two inches. So if you want things smaller, you'd lie in the other direction: tell it your monitor is only 125 DPI, now MuseScore will put 125 pixels up to make something an inch big, and it will end up only half an inch on your system if it's actually 250 DPI.

The GUI scaling parameter is a holdover from before we did any monitor resolution adjustment, so it's really deprecated but might still be useful for some systems, depending on how the OS tries to hide the detail of the system from applications. Unfortunately there is no real standardization for how OS's present resolution info to applications, so in addition to the different resolutions themselves (both at the hardware and OS level), you see things like the partial scaling done by WIndows or ChromeOS, the full scaling done by macOS, the no scaling typically (in my experience) done on Linux, and various Qt environment variables that attempt to sort through the mess. We just do our best to provide options that provide some possibility of getting the GUI to look the same on all these disparate systems, but it's a moving target.

For comparison, here is a screenshot on my system. It's a high DPI Chromebook running MuseScore as a Linux app. Given that ChromeOS/Linux is not doing much scaling for me, I run with "-D 166" and also set my fonts to be 12 pt in Edit / Preferences. But this is how it should look out of the box on "normal" systems. This is how things are designed to look, relatively speaking (absolutely speaking if you view the image the same size as my actual display, which is a 13" display in 16:9 aspect ratio). Note the score itself is "life sized" (same as an actual sheet of letter-sized paper).

Screenshot 2019-12-19 at 1.39.37 PM.png

Reply

• Dec 19, 2019 - 19:06

> Lying about your monitor resolution - telling MuseScore you have higher resolution that you do - will certainly cause things to scale incorrectly. If you tell MuseScore you have a display that is, for example, 500 DPI, then by god, it's going to put 500 pixels up on the screen every time it want to make something an inch big, and if your monitor is actually only 250 DPI, those 500 pixels will take up two inches. So if you want things smaller, you'd lie in the other direction: tell it your monitor is only 125 DPI, now MuseScore will put 125 pixels up to make something an inch big, and it will end up only half an inch on your system if it's actually 250 DPI.

OK. I know and understand all of that. (FWIW, I'm a software developer who specializes in UI, so dealing with this sort of thing is my day job.)

Let's say that, for the sake of argument, the physical size of my monitor is 144 DPI. Windows has historically used a default logical resolution of 96 DPI, so on my system I have to go into Windows Display settings and set the scaling to 150% to bump up the logical resolution to match my physical display. Now if I go into, say, Microsoft Word, I can zoom to 100% and hold a physical ruler up to the virtual ruler on the screen and it lines up exactly. Fantastic.

But when I run MuseScore, I'm not happy with the Inspector window being so tall. When I select a note, the Inspector takes up most of the height on my 4k display, which I don't like because I like to be able to dock other panels below the Inspector and not have to scroll vertically as a result.

So I go into my Windows Display settings and set the scaling to 100%. Now the whole system is running at 96 DPI and everything is 1/3 smaller than it “should” be. In MuseScore, the Inspector now takes up a more reasonable amount of vertical space and I'm happy. (Everything else in MuseScore has shrunk as well, but I'm willing to live with that.) Except that I'm not actually happy because every other app has shrunk, and I can't deal with that. So I go back into my Windows Display settings and set the scaling back to 150%.

I continue to use MuseScore with this low-level annoyance.

One day I'm browsing the MuseScore forums and someone mentions that there's a command-line parameter that allows me to override the DPI detected by MuseScore to anything I want. Great! All I have to do is lie to MuseScore (as you put it) and tell it that my display is 96 DPI and then everything in MuseScore should shrink and look exactly as it did when I did the same thing at the OS level. And best of all, nothing else will be affected — only MuseScore.

Except that it doesn't work. The MuseScore toolbars, instead of shrinking, get bigger! So does the score (when displayed at the same zoom level). And the Inspector, the one thing that I wanted to shrink, stays exactly the same size.

My questions are:

  1. Can you reproduce this behavior?
  2. Why is it doing this? Why doesn't a DPI override of 96 result in the same thing as setting the DPI to 96 at the OS level?

Reply

• Dec 19, 2019 - 20:15

Unfortunately, I cannot tell you what is happening on your computer when you set the DPI to 96 at the OS level, because as I said, every system handles that sort of thing differently. I am not aware of a Windows setting that sets DPI directly, instead there are other settings for resolution in pixels, and a scaling factor that affects some things but not others. So I'm not sure what you're doing exactly, but it isn't really setting the DPI to 96. It might be setting up some sort of emulation, I guess.

What I know is within MuseScore, we query Qt to find the resolution, and scale everything accordingly, so if the OS is being honest about the true resolution in response to that query, you get the behavior we all would hope for: a rule will show the score exactly life size when viewed at 100%. If one the other hand the OS scaling is presenting something to us other than the truth, then we are at a loss.

So if your monitor is truly being set to 96 DPI, then "-D 96" wouldn't even be needed, everything would size correctly by default. Apparently that isn't happening, so all I can do is guess that the setting you are making at the OS level is actually causing the query to return a a value of, say, 72 DPI (another historically significant value).

It's all a bit of a crapshoot with trial and error. If your screen looks roughly like mine, then things are working as designed, If they look significantly different, I'd still like to see a screenshot, to understand and advise better.

Reply

• Dec 19, 2019 - 22:17

> So I'm not sure what you're doing exactly, but it isn't really setting the DPI to 96.

No, it really is. If I write a quick test app and query the system, I get 96 DPI. It's not an emulation or virtualization (which happens only at higher DPI settings under Windows). I don't know what else to tell you.

> So if your monitor is truly being set to 96 DPI, then "-D 96" wouldn't even be needed, everything would size correctly by default. Apparently that isn't happening, so all I can do is guess that the setting you are making at the OS level is actually causing the query to return a a value of, say, 72 DPI (another historically significant value).

The OS is returning correct values. It's possible that Qt is doing something weird with those values before passing them to MuseScore.

To summarize:

  • When I set the display to 96 DPI at the OS level and don't pass MuseScore any command-line parameters, everything works as expected (and looks small).

  • When I set the display to 144 DPI at the OS level and don't pass MuseScore any command-line parameters, everything works as expected (and looks normal-sized).

  • When I set the display to 144 DPI at the OS level and ask MuseScore to override its automatic detection (which normally detects 144 DPI correctly) with 96 DPI (using --monitor-resolution 96), MuseScore malfunctions. (Some things look big and some things look-normal sized, but nothing looks small the way it should.)

In any case, are you able to reproduce the problem I'm describing in the third case? Could you please run MuseScore with an override of 96 DPI and see if everything in MuseScore gets uniformly smaller as it should?

Reply

• Dec 19, 2019 - 23:17

OK, I just had a quick look at the source.

As I suspected, the problem is that Qt is virtualizing the DPI. This is due to a call to QApplication::setAttribute(Qt::AA_EnableHighDpiScaling) inside main(), which happens unconditionally on all platforms.

It's only later on that the --monitor-resolution command-line parameter is handled, inside the constructor of the MuseScore class. Although the code sets some things up when this parameter has been specified, it is not at any point disabling Qt's DPI virtualization by calling QApplication::setAttribute(Qt::AA_DisableHighDpiScaling). As a result, nothing MuseScore does at this point can truly override Qt's DPI virtualization. This explains why the MuseScore-rendered GUI elements are affected by this command-line parameter but the Qt widgets are not.

What I haven't figured out in my quick look is why specifying 96 DPI on the command line causes the MuseScore-rendered things to get larger instead of smaller. I suspect that there's a miscalculation going on, possibly based on an erroneous assumption in the code that the nominal DPI is 96 instead of whatever Qt is currently virtualizing it to.

If and when time allows I will try to set up a build system and investigate this further.

Reply

• Dec 20, 2019 - 03:23

As I mentioned, the are Qt environment variable that can be used to change the behavior, and as far I know (which is isn't as much as I'd like), setting that option is part of that process. On my particular Windows system, I find setting QT_AUTO_SCREEN_SCALE_FACTOR=1 provide most satisifactory results.

I can tell you, though, what setting 96 DPI on the command line actually does. MuseScore normally calculates a value for guiScaling that is applied to the score, palette, and various GUI elements. The scaling value is literally the DPI figure (either reported by Qt, or specified by the user) divided by 96.

So if you are seeing larger things on screen using -D 96, that tells me the guiScaling value (1) is larger in that case than when not using -D 96, which in turn tells me the value actually being returned by Qt is less than 96.

Presumably if/when you get a build system you can either verify this or find out what is going on with your system that causes something other than what this to hold. Again, unfortunately, different systems behave differently in terms of how the scaling is performed at the OS level and at the Qt level. I just know things work as I expect on the dozen or so different configurations I have been able to test.

Reply

• Dec 20, 2019 - 03:09

Thanks for your investigation! I'm on vacation next couple of weeks and don't have my Windows system with me so I can't test further, but I can tell you mine has no place to set a DPI. It has a scaling setting, sure, but setting it to 100% does not cause the display to become 96 DPI. When set to 100%, everything is tiny on all applications, which is what I expect when no scaling is performed, because the resolution is not 96 DPI. Maybe we have different notions of what it means to set a monitor to 96 DPI. To me, it means setting it so that a 96x96 pixel PNG file renders one inch square, and that's not what happens at 100% scaling.

Reply

Do you still have an unanswered question? Please log in first to post your question.