Some dropdown menus (e.g., in Mixer) start scrolling through options when mouse passes over them while scrolling
I use the scroll wheel a lot, also at mixer panel... the problem is that everything on that panel gets affected by the mouse wheel and it keeps changing values that I don't want to change, specially instruments.
I would suggest that the mouse wheel would only make the mixer panel go up and down and that a modifier key would be used if you wanted to change any values under the mouse (Ctrl + Mouse wheel for instance).
It is kind of "ok" at the right side of the mixer (volume, pan, etc) but... it's not good when you have your mouse to the left and you use the wheel... then you press Play and realize you've changed a bunch of sounds :(
Comments
What version and OS are you using?
Nightly.
Win8 64
Hmm, maybe I just have different expectation that you, but I think the current behavior is correct. If the focus is on a spinbox or other control, I *want* mouse wheel to affect it. And a person who uses the keybaord as much as possible, it's a bug to me if no editable field has focus when I open a dialog/window.
I suppose somewhere Microsoft & Apple probably publish guidelines for such matters, but it's important consider accessibility here as well. For a blind user, scroll wheel to activate scroll bars is useless; much better is for it to work the currently-selected control.
Iam not so sure about that... all the DAW's I've used will give you at least a way to choose and if they don't, they won't be scrolling everything that happens to be under the mouse, that would get us nowhere lol
If you click something, then you should be able to scroll through... but just by having the mouse on top of the window, the scroll should work as it does everywhere (internet browsers and such) by scrolling the page no matter where your mouse pointer is.
I don't know what you mean about "scrolling everything that happens to be under the mouse". Thats not how MuseScore works. The scroll wheel affects the one and only one control that has focus. The question is whether it is better to be able to easily use the wheel to modify the currently-selected value or to be able to scroll. I personally find the former more valueable, and figure a blind user will feel similarly. But I can see why some might prefer scrolling by default. Which again is why I wonder if there are published guidelines here.
It is highly irregular for scrolling with the mouse passing over a dropdown menu to change the selection in that dropdown, unless you first click on the dropdown (or use [Tab] to select it). This is particularly problematic in the Mixer, though, because as you start scrolling down in the dialog, a dropdown menu may move up to under the mouse without the mouse being moved over the menu—at which point the window will stop scrolling while the dropdown flips through options.
Reported again at https://musescore.org/en/node/123951.
FWIW, I do agree the current system leaves somethng to be desired, as it is indeed too easy to inadvertently modify values while attempting to scroll. I would maintain, however, that is important to make sure the Mixer is navigable by keyboard and that we pay close attention to the issue of focus and making the behavior consistent with expectations and generally accepted GUI guidelines.
My own expectations, based on experience with any number of other programs, are in comment # 6 above:
"It is highly irregular for scrolling with the mouse passing over a dropdown menu to change the selection in that dropdown, unless you first click on the dropdown (or use Tab to select it)."
Yes. The question to me is mostly about what the *initial* state of the window should be - where the focus should be for keyboard control, what scroll wheel should do in that state, etc.
Somewhat fixed by 8b4d8f1, where the UI has just begun a major redesign. The particular problem of the sound selector, instead of the whole window, scrolling when it happens to be under the mouse has gone away. However, the window stops scrolling, too.
Can no longer reproduce any problems in master. Dates back at least to b519c87 and probably earlier.
Automatically closed -- issue fixed for 2 weeks with no activity.