Intending to scroll Inspector panel modifies property value if cursor is above
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
I think this is by design. You can drag the panel on the right ;-)
In reply to I think this is by design… 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 If this is by design, then I… 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 :-)
In reply to If this is by design, then I… by hiddenhare
What if "Ctrl + scroll" is the way to alter values while scroll is the way to, you know, scroll? This is a better design in my opinion. This issue of MuseScore has been troubling me too.
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.
In reply to This is probably a duplicate… by mike320
I don't see a thread in the issue tracker about this other than this one, so I guess this one isn't a "duplicate", though it has probably been discussed in the forum earlier.
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 This is not specific 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 Marc: Can't speak for other… 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)
This is bad behaviour, I agree. A good solution is to only accept scrolling if the widget is focussed. I have managed to implement this and will have a PR up shortly :)
https://github.com/musescore/MuseScore/pull/5665
Although a PR already exists, I'm merely mentioning that this too has been an issue for me at times with scrolling. Because of that, I have tried adapting away from doing so and click-drag because of the possibility of screwing some field-data up, and it would be nice to demand a click into a particular [field] before changing anything specific.
And for what it's worth, based on some of what Tantacrul mentioned about design changes related to the inspector panel, maybe this problem will be less of an issue anyways when some cleaning/neatening up gets implemented. Either way, the pull request seems agreeable over here.
> design changes related to the inspector panel
It's more of a complete overhaul ;-)
Fixed in branch master, commit ff08e84900
_fix #297176: prevent scrolling on non-focussed spinboxes and comboboxes
This adds an event filter to all spinboxes and comboboxes in the inspector, which catches scroll events when not focussed,
and prevents them from being passed further along. This requires setting the Qt::StrongFocus policy on each of these widgets._
Fixed in branch master, commit 1ba354e5a9
_Merge pull request #5665 from jthistle/297176-scroll-prevent-inspector
fix #297176: prevent scrolling on non-focussed spinboxes and comboboxes_
Automatically closed -- issue fixed for 2 weeks with no activity.