The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
RFC natural scrolling handling on Mac OS X
urkle


Joined: 23 Sep 2012
Posts: 77
Sam,

I've finally gotten to redoing this patch..


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-366-7906

On Mar 1, 2014, at 17:42, Edward Rudd wrote:
Quote:
Awesome.. I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:
Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing? I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference. I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!! I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad", a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly", A user-space input remapper. no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games.. it's all about the games.. Specifically ZenBound2 ignores the
natural scrolling choice. But I'm sure other games on OS X do this as
well.. e.g. scroll "up" to switch to the next weapon.. you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling.. Or "zoom in on the map scroll up" same thing. There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:) So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application.. so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things. Add the flag to the SDL event.wheel.natural (0 off, 1 natural). And then default it to follow the user-setting. And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
RFC natural scrolling handling on Mac OS X
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
In general, without context it seems weird that sometimes you'll get reversed input, especially with the comment in the header.  "Why would they be reversed, WTF?" Maybe expand the comment to describe when and why this would happen? Also maybe change the enumeration to NORMAL and NATURAL, to indicate intent?

Here are a few more notes:
* Typo: When REVSERED
* Type is Uint32, but cast to int: event.wheel.reversed = (int)reversed;
* Instead of "reversed", can you change it to "direction"? It's not a bool, it's an enumeration.




On Sun, Nov 23, 2014 at 7:57 PM, Edward Rudd wrote:
Quote:
Thanks Andreas,

I'll make those fixes.. Other than that, did you see any issues with the how things are exposed in the API?

On Nov 23, 2014, at 22:27, Andreas Schiffler wrote:

Quote:
Quote:
Hi Edward - I've got 3 code review comments:

- Typo:
33: ... When REVSERED the values ... - should read REVERSED

- wrong cast:
91: event.wheel.reversed = (int)reversed; - should be (Uint32)reversed
since 33: + Uint32 reversed

- Wrong enum:
265: SDL_SendMouseWheel(window, 0, 0, motion, SDL_MOUSE_NORMAL); - should use SDL_MOUSEWHEEL_NORMAL

Cheers,
Andreas

On 11/23/2014 6:19 PM, Edward Rudd wrote:

Quote:
Sam,

I've finally gotten to redoing this patch..  


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Mar 1, 2014, at 17:42, Edward Rudd wrote:

Quote:
Awesome..    I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:

Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing?  I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference.  I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!!  I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad",  a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly",  A user-space input remapper.  no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games..  it's all about the games..   Specifically ZenBound2 ignores the
natural scrolling choice.  But I'm sure other games on OS X do this as
well..  e.g. scroll "up" to switch to the next weapon..  you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling..  Or "zoom in on the map scroll up" same thing.   There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI  you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:)  So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application..   so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things.  Add the flag to the SDL event.wheel.natural (0 off, 1 natural).  And then default it to follow the user-setting.  And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org








RFC natural scrolling handling on Mac OS X
urkle


Joined: 23 Sep 2012
Posts: 77
I thought about naming it direction instead of reversed as well.. I can call it direction instead as that does make it clearer.


The reason I went with with REVERSED for the enum was that "natural" is an apple "opinion" on their naming.. and wasn’t sure if that would be universally understandable across platforms. maybe NORMAL and FLIPPED ?



I updated the gist diff.. (also noticed some accidental find/replace changes that should not have occured)




On Nov 29, 2014, at 2:33 PM, Sam Lantinga wrote:
Quote:
In general, without context it seems weird that sometimes you'll get reversed input, especially with the comment in the header. "Why would they be reversed, WTF?" Maybe expand the comment to describe when and why this would happen? Also maybe change the enumeration to NORMAL and NATURAL, to indicate intent?

Here are a few more notes:
* Typo: When REVSERED
* Type is Uint32, but cast to int: event.wheel.reversed = (int)reversed;
* Instead of "reversed", can you change it to "direction"? It's not a bool, it's an enumeration.





Quote:
On Sun, Nov 23, 2014 at 7:57 PM, Edward Rudd wrote:
Quote:
Thanks Andreas,

I'll make those fixes.. Other than that, did you see any issues with the how things are exposed in the API?

On Nov 23, 2014, at 22:27, Andreas Schiffler wrote:

Quote:
Quote:
Hi Edward - I've got 3 code review comments:

- Typo:
33: ... When REVSERED the values ... - should read REVERSED

- wrong cast:
91: event.wheel.reversed = (int)reversed; - should be (Uint32)reversed
since 33: + Uint32 reversed

- Wrong enum:
265: SDL_SendMouseWheel(window, 0, 0, motion, SDL_MOUSE_NORMAL); - should use SDL_MOUSEWHEEL_NORMAL

Cheers,
Andreas

On 11/23/2014 6:19 PM, Edward Rudd wrote:

Quote:
Sam,

I've finally gotten to redoing this patch..


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Mar 1, 2014, at 17:42, Edward Rudd wrote:

Quote:
Awesome.. I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:

Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing? I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference. I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!! I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad", a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly", A user-space input remapper. no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games.. it's all about the games.. Specifically ZenBound2 ignores the
natural scrolling choice. But I'm sure other games on OS X do this as
well.. e.g. scroll "up" to switch to the next weapon.. you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling.. Or "zoom in on the map scroll up" same thing. There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:) So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application.. so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things. Add the flag to the SDL event.wheel.natural (0 off, 1 natural). And then default it to follow the user-setting. And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org










RFC natural scrolling handling on Mac OS X
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
Looks good, go ahead and push it.

Thanks!


On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd wrote:
Quote:
I thought about naming it direction instead of reversed as well..      I can call it direction instead as that does make it clearer.


The reason I went with with REVERSED for the enum was that "natural" is an apple "opinion" on their naming.. and wasn’t sure if that would be universally understandable across platforms.    maybe  NORMAL and FLIPPED ?



I updated the gist diff.. (also noticed some accidental find/replace changes that should not have occured)




On Nov 29, 2014, at 2:33 PM, Sam Lantinga wrote:

Quote:
In general, without context it seems weird that sometimes you'll get reversed input, especially with the comment in the header.  "Why would they be reversed, WTF?" Maybe expand the comment to describe when and why this would happen? Also maybe change the enumeration to NORMAL and NATURAL, to indicate intent?

Here are a few more notes:
* Typo: When REVSERED
* Type is Uint32, but cast to int: event.wheel.reversed = (int)reversed;
* Instead of "reversed", can you change it to "direction"? It's not a bool, it's an enumeration.





Quote:
On Sun, Nov 23, 2014 at 7:57 PM, Edward Rudd wrote:
Quote:
Thanks Andreas,

I'll make those fixes.. Other than that, did you see any issues with the how things are exposed in the API?

On Nov 23, 2014, at 22:27, Andreas Schiffler wrote:

Quote:
Quote:
Hi Edward - I've got 3 code review comments:

- Typo:
33: ... When REVSERED the values ... - should read REVERSED

- wrong cast:
91: event.wheel.reversed = (int)reversed; - should be (Uint32)reversed
since 33: + Uint32 reversed

- Wrong enum:
265: SDL_SendMouseWheel(window, 0, 0, motion, SDL_MOUSE_NORMAL); - should use SDL_MOUSEWHEEL_NORMAL

Cheers,
Andreas

On 11/23/2014 6:19 PM, Edward Rudd wrote:

Quote:
Sam,

I've finally gotten to redoing this patch..  


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Mar 1, 2014, at 17:42, Edward Rudd wrote:

Quote:
Awesome..    I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:

Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing?  I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference.  I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!!  I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad",  a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly",  A user-space input remapper.  no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games..  it's all about the games..   Specifically ZenBound2 ignores the
natural scrolling choice.  But I'm sure other games on OS X do this as
well..  e.g. scroll "up" to switch to the next weapon..  you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling..  Or "zoom in on the map scroll up" same thing.   There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI  you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:)  So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application..   so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things.  Add the flag to the SDL event.wheel.natural (0 off, 1 natural).  And then default it to follow the user-setting.  And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org















RFC natural scrolling handling on Mac OS X
urkle


Joined: 23 Sep 2012
Posts: 77
It’s pushed.. and all the builds are passing now.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-366-7906

On Dec 2, 2014, at 3:03 AM, Sam Lantinga wrote:
Quote:
Looks good, go ahead and push it.

Thanks!


On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd wrote:
Quote:
I thought about naming it direction instead of reversed as well.. I can call it direction instead as that does make it clearer.


The reason I went with with REVERSED for the enum was that "natural" is an apple "opinion" on their naming.. and wasn’t sure if that would be universally understandable across platforms. maybe NORMAL and FLIPPED ?



I updated the gist diff.. (also noticed some accidental find/replace changes that should not have occured)




On Nov 29, 2014, at 2:33 PM, Sam Lantinga wrote:

Quote:
In general, without context it seems weird that sometimes you'll get reversed input, especially with the comment in the header. "Why would they be reversed, WTF?" Maybe expand the comment to describe when and why this would happen? Also maybe change the enumeration to NORMAL and NATURAL, to indicate intent?

Here are a few more notes:
* Typo: When REVSERED
* Type is Uint32, but cast to int: event.wheel.reversed = (int)reversed;
* Instead of "reversed", can you change it to "direction"? It's not a bool, it's an enumeration.





Quote:
On Sun, Nov 23, 2014 at 7:57 PM, Edward Rudd wrote:
Quote:
Thanks Andreas,

I'll make those fixes.. Other than that, did you see any issues with the how things are exposed in the API?

On Nov 23, 2014, at 22:27, Andreas Schiffler wrote:

Quote:
Quote:
Hi Edward - I've got 3 code review comments:

- Typo:
33: ... When REVSERED the values ... - should read REVERSED

- wrong cast:
91: event.wheel.reversed = (int)reversed; - should be (Uint32)reversed
since 33: + Uint32 reversed

- Wrong enum:
265: SDL_SendMouseWheel(window, 0, 0, motion, SDL_MOUSE_NORMAL); - should use SDL_MOUSEWHEEL_NORMAL

Cheers,
Andreas

On 11/23/2014 6:19 PM, Edward Rudd wrote:

Quote:
Sam,

I've finally gotten to redoing this patch..


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Mar 1, 2014, at 17:42, Edward Rudd wrote:

Quote:
Awesome.. I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:

Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing? I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference. I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!! I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad", a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly", A user-space input remapper. no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games.. it's all about the games.. Specifically ZenBound2 ignores the
natural scrolling choice. But I'm sure other games on OS X do this as
well.. e.g. scroll "up" to switch to the next weapon.. you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling.. Or "zoom in on the map scroll up" same thing. There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:) So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application.. so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things. Add the flag to the SDL event.wheel.natural (0 off, 1 natural). And then default it to follow the user-setting. And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

















RFC natural scrolling handling on Mac OS X
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
Great, thanks!

On Wed, Dec 3, 2014 at 8:10 AM, Edward Rudd wrote:
Quote:
It’s pushed..  and all the builds are passing now.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Dec 2, 2014, at 3:03 AM, Sam Lantinga wrote:

Quote:
Looks good, go ahead and push it.

Thanks!


On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd wrote:
Quote:
I thought about naming it direction instead of reversed as well..      I can call it direction instead as that does make it clearer.


The reason I went with with REVERSED for the enum was that "natural" is an apple "opinion" on their naming.. and wasn’t sure if that would be universally understandable across platforms.    maybe  NORMAL and FLIPPED ?



I updated the gist diff.. (also noticed some accidental find/replace changes that should not have occured)




On Nov 29, 2014, at 2:33 PM, Sam Lantinga wrote:

Quote:
In general, without context it seems weird that sometimes you'll get reversed input, especially with the comment in the header.  "Why would they be reversed, WTF?" Maybe expand the comment to describe when and why this would happen? Also maybe change the enumeration to NORMAL and NATURAL, to indicate intent?

Here are a few more notes:
* Typo: When REVSERED
* Type is Uint32, but cast to int: event.wheel.reversed = (int)reversed;
* Instead of "reversed", can you change it to "direction"? It's not a bool, it's an enumeration.





Quote:
On Sun, Nov 23, 2014 at 7:57 PM, Edward Rudd wrote:
Quote:
Thanks Andreas,

I'll make those fixes.. Other than that, did you see any issues with the how things are exposed in the API?

On Nov 23, 2014, at 22:27, Andreas Schiffler wrote:

Quote:
Quote:
Hi Edward - I've got 3 code review comments:

- Typo:
33: ... When REVSERED the values ... - should read REVERSED

- wrong cast:
91: event.wheel.reversed = (int)reversed; - should be (Uint32)reversed
since 33: + Uint32 reversed

- Wrong enum:
265: SDL_SendMouseWheel(window, 0, 0, motion, SDL_MOUSE_NORMAL); - should use SDL_MOUSEWHEEL_NORMAL

Cheers,
Andreas

On 11/23/2014 6:19 PM, Edward Rudd wrote:

Quote:
Sam,

I've finally gotten to redoing this patch..  


Could you give it a once-over and give your thoughts before I push the commits ?


https://gist.github.com/urkle/3c398a19c811f0865c17

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
[url=tel:317-366-7906]317-366-7906[/url]

On Mar 1, 2014, at 17:42, Edward Rudd wrote:

Quote:
Awesome..    I’ll re-work the path and commit it up AFTER 2.0.2 final is released.


On Mar 1, 2014, at 2:55 PM, Sam Lantinga wrote:

Quote:
That sounds good to me. I recently got access to a Windows 8 laptop which appears to have natural scrolling behavior by default, so I can implement this flag on Windows.

This will be for 2.0.3.


Thanks!



On Sat, Mar 1, 2014 at 11:41 AM, Edward Rudd wrote:
Quote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

Quote:
On 2/26/14, Edward Rudd wrote:
Quote:
On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn
wrote:

Quote:
Does anyone know if there's a Windows API function to detect the same
kind
of thing?  I worked on a Dell laptop a couple weeks ago that had
inverted
touchpad scrolling by default and I wonder if Windows is aware of the
difference.  I might have seen something for Win8, which would make
sense,
but what about earlier versions?

From my experience, most of those have been features of mouse drivers,
not
an OS level feature, thus it's been isolated away from the developer
knowing
about it at all.

Oh dear!!  I did a quick google, and it's scary what's out there.

This page summarizes the ones I've found..

http://superuser.com/questions/310681/inverting-direction-of-mouse-scroll-wheel

So, we have the "bad",  a flag on the HID device parameters. not really
easy
to grab with in SLD2

and the "ugly",  A user-space input remapper.  no real way to detect
that.

So, basically there's no API in Windows let alone even a standard
configuration setting from what I can tell.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


As shown in the above link, there are two Windows registry keys that
invert the scrollwheel. There is no UI to set these, but these are
actual Microsoft keys, hence the closest you get to an OS level
service. (Yes, I use these on my Windows machine and they do work as
one would expect across all your applications transparently.)

They are FlipFlopWheel and FlipFlopHScroll. You have to relogin for
the registry setting to take effect, so they can't change while your
app is running. You could query the registry for these values if you
really wanted to try to bring Windows to parity with this API.

However, there is added complexity there of knowing which input device
triggered the mouse scroll so as to know which setting to check against..

Quote:
I'm curious, what use case do you have that needs to ignore natural
scrolling? In practice, I don't think I've actually encountered a
real-world program that has had to do this (or at least has gone to
the effort and I failed to notice).

Games..  it's all about the games..   Specifically ZenBound2 ignores the
natural scrolling choice.  But I'm sure other games on OS X do this as
well..  e.g. scroll "up" to switch to the next weapon..  you'd want that to
always be true as your documentation says so.. thus you'd want to ignore the
natural scrolling..  Or "zoom in on the map scroll up" same thing.   There
are many cases where you do actually want to ignore the setting, and many
others where you don't.. e.g. in a scroll list in your UI  you would want to
respect the natural setting.


This was a genuine question. I do believe there are use cases, I just
haven't seen any compelling real world cases, so I've been looking for
them. (I think I've seen ZenBound2 on an iPad but haven't played it
and not a Mac so I can't judge.)

However, scroll wheel inversion for weapon selection is a terrible
case in my opinion because the whole notion of direction is arbitrary
to begin with in this case. What I expect as the end user in this case
is consistency with the OS in the absence of a logical reason. (Once a
user becomes accustomed to the direction of the scrolling on the
system, they stop thinking about it as long as everything else remains
consistent.) Otherwise, you will just irritate users like me as.
Ignoring natural scrolling on a Mac by default without a real
compelling reason (documentation isn't compelling; nobody reads
documentation, and could be reworded) is an invitation for hate by Mac
users.



It has to be documented in the SDL API somehow:)  So if we do “user choice of natural” by default (As it is now) and pass down the flag, we document it for the developer.

Quote:
Also, as mentioned, differentiating between the track pad scrolling
and mouse scrolling is a thing that Apple, by intent, will make hard.


However, Apple did not make it hard. They exposed a very clear method in the NSEvent to detect this behavior, and even added documentation that “we” the developers may want to ignore the setting based on the context in our application..   so the goal of this patch is really to expose the setting down to the developer so we have the same choice in SDL 2 as we do writing native OS X as I’ve seen uses in the wild in games that I’ve ported and have had to patch SDL2 to make it happen.. So I’d rather move this upstream in an acceptable manner.

So my proposal now is to simplify things.  Add the flag to the SDL event.wheel.natural (0 off, 1 natural).  And then default it to follow the user-setting.  And document it in the wiki/header file so we don’t get developers confusing the fact they they have natural scrolling enabled on their system to mess up the behavior for other users who have it disabled.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org