-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mouse wheel scrolling applied on Hovered (currently) vs Focused (more standard?) #1245
Comments
This behaviour (hovered window to scroll) seems to be same as macOS. |
OK good to know, I didn't know this was what Mac was doing. (PS: like or not Windows is more standard, especially for game developers ;) In the test window right now I am finding it very unpleasant when mouse-scrolling down and then because of the scrolling the mouse end up Hovering the ListBox of the demo and then suddenly the child window start scrolling instead of the parent window. Does Mac have the same issue? |
Yes macOS has the exact same behaviour. |
Personally I like mac behaviour in that regard, with an exception to scrolling direction. What it calls 'natural' I call 'akward'. Chrome Browser use this behavior too. From the UX stand point I'm satisfied because I don't have to make an extra click to achieve desired result. Simply move mouse and scroll. Scrolling lists in lists is rarely surprising. Usually moving mouse to outer area of inner widget does the trick. |
OK, dropping that idea for now based on your feedback. May organize the demo window later so it doesn't happen as much. |
Hello,
Currently the mouse wheel scrolling behavior is that we scroll whichever window/child is being HOVERED as opposed to FOCUSED (clicked on).
The current behavior can be a little more error prone, but perhaps occasionally is faster to use,
The later seems more standard, at least this is what Windows is doing.
I've been thinking about changing it.
Does anyone have an opinion on doing this? How would that impact your applications?
(One required side-effect is that it may be better if we highlighted the focused child more consistently - something that the Navigation branch (#787) is already doing when using gamepad/keyboard. But even if we didn't the interaction would still be rather obvious to the end-user)
The text was updated successfully, but these errors were encountered: