Skip to content
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

Closed
ocornut opened this issue Jul 23, 2017 · 6 comments

Comments

@ocornut
Copy link
Owner

ocornut commented Jul 23, 2017

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)

@ocornut ocornut changed the title Poll: Mouse wheel scrolling on Focused vs Hovered Mouse wheel scrolling applied on Hovered (currently) vs Focused (more standard?) Jul 23, 2017
@CyberMew
Copy link

This behaviour (hovered window to scroll) seems to be same as macOS.

@itamago
Copy link

itamago commented Jul 27, 2017

The current behaviour, same as macOS, has a the benefit to send scroll-input to a window without putting it in front of the others.
I am used to both macOS and win10, and clearly I prefer the macOS window behaviour : if you have multiple opened windows, you can scroll one or the other without changing the focus.

More specifically about ImGui : when you have a list full of widgets, the current behaviour allows to scroll into the list without clicking on a widget (which may activate something by error).

Example of list where you prefer not click by error :
screen shot 2017-07-27 at 14 14 05

[Edit] I wouldn't say "Focused (more standard)" but "Focused (more Windows-like)"

@ocornut
Copy link
Owner Author

ocornut commented Jul 29, 2017

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?

@itamago
Copy link

itamago commented Jul 31, 2017

Yes macOS has the exact same behaviour.
You may call it an issue or a feature, depending how you consider it.
I see it as a feature : being able to scoll anything by hovering with a mouse pointer, and the reasons I explained before (not being forced to click on a widget).
Some may see it as an issue, yes..

@thedmd
Copy link
Contributor

thedmd commented Aug 1, 2017

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.

@ocornut
Copy link
Owner Author

ocornut commented Aug 5, 2017

OK, dropping that idea for now based on your feedback. May organize the demo window later so it doesn't happen as much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants