Inspector is too wide

• Nov 18, 2018 - 10:55
Reported version
P2 - Medium
Graphical (UI)
S5 - Suggestion

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: db594ae

There needs to be a significant reduction in the minimum width of the Inspector (i.e. the width necessary to just accomodate all the Inspector widgets and text), which has increased significantly from 2.x to 3.0-dev. The following measurements were made with a note selected on a 1680 x 1050 screen:

  • MS 2.x = 6.5 cm.
  • MS 3.0-dev = 8.5cm.

See also, #276503: Inspector: minimum width changes depending on element selected.


Not sure what exactly you're measure there, for me the difference in minumum with of a note instecpire (made as narrow as possible without a hozsontal slider to show) is pretty minimal, 7,8mm vs. 7mm. 20" screen with 1600x1200 pixels

Screenshots from the bottom of the Inspector (note selected, horizontal scroll bar just disappeared):

Type Functional Graphical (UI)
Priority P2 - Medium

Specific sizes will probably vary from system to system according to resolution, fonts, etc. But no denying the Inspector has gotten generally wider -- it does, after all, contain significantly more controls for most elements. The price of eliminating properties dialogs. Still, there are some of the individual panes that could be designed a bit more efficiently, also a number that just have arbitrary sizes specified in excess of what is needed. Someone who is good at this sort of thing should go through each of those inspector_*.ui files and see what can be done, because I agree it would be nice if the width requirement could be reduced in general. I suppose a tradoff is against height, but I don't mind occasionally needing to scroll vertically

I got curious about the discrepancy between frame and other text. Turns out the cause is simple: the units for the offset field are "mm" instead of "sp", and "mm" is wider, thus forcing that row to be wider, which is the determining factor here. Not sure that's worth doing anything about.

As for the text lines, the big difference seems to be the label "Alignment" that appears next to the alignment buttons for the begin/continue/end text. The corresponding buttons on regular text aren't labeled (same for "Font face", etc).

Another note: since it seems to be the combing of the X & Y offset fields into one line that is the determining factor of width for many elements, maybe we just return that to separate lines? I have a sense this was done for a reason - maybe to share a reset button? - but perhaps it wasn't worth it? Or we keep the controls on one line, but move the label above?