Intending to scroll Inspector panel modifies property value if cursor is above

• Nov 16, 2019 - 10:54
Reported version
3.3
Type
Ergonomical (UX)
Frequency
Few
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

MuseScore 3.3.2.8849, revision 492d7ef. Windows 10, 64-bit, HiDPI display with resolution 1920x1080, UI scaling 150% (so, equivalent to a 1280x720 screen without UI scaling).

Whenever I attempt to navigate using the scroll wheel, if the mouse cursor happens to be over a spin box or combo box, that control will capture the scroll-wheel input, prevent scrolling from occuring, and change its own value instead. This is inconsistent with other applications, and it makes an important navigation tool very difficult to use. It sometimes causes me to change values without noticing, which can have unpredictable effects.

This usually occurs in the "Inspector" panel, which has many spin boxes and combo boxes. However, it also occurs in any dialog which contains both a scrollbar and a spin box or combo box - for example, "Edit/Preferences/Advanced", "Edit/Instruments", and "Format/Style".


Comments

Title When scrolling the Inspector panel using the mouse wheel, spin box and combo box controls may capture input, prevent scrolling, and change their value Intending to scroll Inspector panel modifies property value if cursor is above

In reply to by Howard-C

If this is by design, then I definitely disagree with the design! I've been using MuseScore fairly regularly for over a year now, and I'm still frequently tripped up by this problem. Even when I remember that I need to work around it, I find that scrolling by dragging the scrollbar is always slower and more awkward than using the mousewheel.

In general, having the scroll wheel do anything other than scroll or zoom strikes me as bad UX. Google Maps' embedded widgets in webpages used to have the same problem, it was a well-known annoyance, and it was eventually replaced by "ctrl + scroll to zoom".

By analogy, it feels as though the "Caps Lock" key has been given a special function when typing in lyrics, so to type in uppercase words I'm forced to hold down "Shift" instead... yes, I could learn to work around it, but it seems unwise to hijack such a fundamental input tool.

In reply to by hiddenhare

Personally I can never understand why you are willing to bother pressing CapsLock twice before and after upper case character instead of holding Shift which no longer takes effect after being released. The latter is much simpler and less troublesome.

EDIT: I misread your post, and yes, if inputing whole words that are upper case, then CapsLock is useful. But I'm afraid I've never used that even once when inputing text. Just like you aren't accustomed to Shift, I'm not accustomed to CapsLock :-)

Frequency Once Few

This is probably a duplicate from several years ago. It's been this way since at least version 2.something and I complained about it a long time ago. Since this design flaw isn't being fixed I've gotten used to avoiding spin boxes by moving my mouse closer to the slider bar and spinning my mouse wheel there to avoid spin boxes.

I think most of the complaints I remember about this were from the Mixer, but same principles apply, would be nice to be consistent. I can't say I like the current behavior either, but I'm also wondering if maybe this behavior depends on OS and system settings, kind of like whether the window gets focus on hover or not.

This is not specific to MuseScore at all.
It is well known that spinner can be changed by scroll wheel.
I manage a large set of users for different applications and indeed first time they expirement that some of them don't like it.
A good design rule is to always avoid to use a spinner as first field of a form (the one getting focus when the form is opened), this way, the most common issue being opening the form, "scrolling" and in fact unvoluntary changing the first field is avoided.
Just doing that (avoid using spinner as first form field) makes 99,99% of the users happy.

In reply to by frfancha

Marc: Can't speak for other platforms, but I tested a few other Win32 applications (applications made by Microsoft, which don't use a cross-platform widget toolkit). It looks like there's no standard convention on this platform. Combo boxes intercept mouse-wheel input in Notepad's "Font" dialog and most of the old-fashioned control panel applications, but not in the new-style "Settings" app, the "Print Preferences" dialog, the "File Open" dialog, or MS Paint's new Ribbon interface. I wasn't able to find any applications which have a spin box or combo box nested within a scrollbar (possibly suggesting that it's not a good idea in the first place...). Microsoft's Win32 and Metro UX guidelines don't have any relevant advice.

My knowledge of Qt is a bit patchy, but I believe it's possible to configure spin boxes and combo boxes so that they don't receive focus from mouse-wheel events.

frfrancha: Unfortunately, that wouldn't be a solution in this case, because the spin boxes are capturing scroll-wheel input even when they don't have the keyboard or mouse focus, just because the cursor happens to be hovering over them.

In reply to by hiddenhare

<< capture mouse wheel events without keyboard focus >>
In that case I would certainly call that a bug!
Spinners (and related fields) must capture scroll-wheel events only if they have been given focus in the first place.
EDIT: Although if you have to put the mouve over the field in the first place, why not...
I wasn't aware of that possibility and had never used a combobox or spinner that way (without first giving it focus I mean).
Your post made me curious and I have just checked the font dialog of Notepad and was surprised)