Editing text line causes inspector to jump if Inspector requires horizontal scrollbars

• Nov 1, 2020 - 04:57
Reported version
Ergonomical (UX)
S4 - Minor

This is quite annoying. When you add a hairpin and edit a text that is not included in the definition of the hairpin, when you click the check box for the new text then click in the box to enter the text, the display jumps so you cannot see the check box. This is what happens in my symphonic scores. In a scratch score I created an animated GIF, but the jump does not happen, but when you check the end text box, the text field is revealed, when you click in the text field, it closes and you must check the box again before you can enter the text.

Here is an example from a long score I'm currently working on:

line text jump.gif


I have experienced this for what seems like years now, but never mentioned it since I supposed maybe it was a Linux quirk or something with Qt. I can attest its annoyance.

Type Functional Ergonomical (UX)

I find I can reproduce this only if I shrink my Inspector so be narrow enough to need scroll bars, is that your experience also?

Probably it is something about how Qt manages focus, but it's also possible there are some settings we could make that would improve the situation.

I've found that the jump happens on true hairpins (> and <) but I have to click the boxes again even though there is no jump in the text type hairpins (dim. & cresc.). I have scroll bars on both of these in my normal view.

Title Editing text line causes inspector to jump Editing text line causes inspector to jump if Inspector requires horizontal scrollbars

OK, I'm going to assume then it really is specifically about the scroll bar case. I always have my Inspector wide enough to never need scrollbars. In general, if scrollbars are present, there are always going to be issue to trade off against each other - anything that moves focus from a field currently visible to one currently not visible will either cause the view to jump or will cause the focus to not be visible, no getting around the laws of physics on that. So it's impossible to make the scrollbar case perfect. But it can certainly be improved in cases where it seems there is consensus as to what the less-undesriable behavior would be.

I can reproduce this with very wide Inspector, without horizontal scrollbars. Moreover, the same thing happens even if no vertical scrollbars are needed (for example, if other sections of Inspector are collapsed): when clicking on a text field under "Begin/Continue/End text" checkboxes for the first time, that checkbox gets automatically unchecked so it needs to be checked back to allow editing that text field.

I believe a factor that makes the jump worse is that I don't maximize MuseScore when I use it. The GIF I attached shows my normal view when I use the program.

To be clear, it's the "jump" part that I think only applies when there are scrollbars. The part about the checkbox behavior itself is, as mentioned, a separate issue, and it indeed does not depend on the presence of scrollbars.