RFC natural scrolling handling on Mac OS X

So, Apple has created this “lovely” behavior on Mac OS X 10.7+ called natural scrolling (or unnatural depending on who you are). At least Apple did make a method to check if the user requested natural scrolling…

One of the games I’m updating for a customer to SDL2 explicitly checked for this “flag” in the mouse scroll events so they could negate it if set. As there are times (especially in games) where you do not want the “natural” feel in certain parts of your game…But other ares you do. and Apple’s documentations even accounted for that.

(From the Apple documentation for NSEvent )

The direction of fluid swipes matches the direction of scrolling and as such for NSEventTypeSwipe events gestureAmount is inverted. However, for some uses of NSEventScrollWheel and NSEventTypeSwipe events, the behavior should not respect the user preference. This method allows you to determine when the event has been inverted and compensate by multiplying -1 if needed.

So I propose V1 of my patch to address this.

This patch adds an extra property to the SDL_MouseWheelEvent that denotes if natural scrolling has been enabled by the user. It also reverses the directions by default for OS X so all scroll events are consistent across all platforms and “natural” settings… Thus if you the developer wish to have the natural feel the user requested you can simply multiply (event.wheel.y * event.wheel.natural) and get the corrected direction.

The data is passed via the event as the user CAN change the setting while your application is running. Also the setting can be set differently based on the input device… e.g. a mouse have it off, but a trackpad have it on. Thus a single function SDL_IsMouseWheelInverted() just doesn’t work cleanly.

I also chose to make event.wheel.natural either 1 or -1 so a simple multiplication can apply the user preference easily.

Comments on the event field name and other choices are welcome.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

-------------- next part --------------
A non-text attachment was scrubbed…
Name: natural_scrolling.diff
Type: application/octet-stream
Size: 7859 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140225/17eb5cb4/attachment-0001.obj

I like the patch in general. I think you may be too clever with the
multiplication of the value to get the natural motion. If you want to keep
that semantic maybe you can rename it something more clear like
"natural_motion_multiplier" or “natural_direction_multiplier”.On Tue, Feb 25, 2014 at 6:43 PM, Edward Rudd wrote:

So, Apple has created this “lovely” behavior on Mac OS X 10.7+ called
natural scrolling (or unnatural depending on who you are). At least Apple
did make a method to check if the user requested natural scrolling…

One of the games I’m updating for a customer to SDL2 explicitly checked
for this “flag” in the mouse scroll events so they could negate it if set.
As there are times (especially in games) where you do not want the
"natural" feel in certain parts of your game…But other ares you do. and
Apple’s documentations even accounted for that.

(From the Apple documentation for NSEvent )

The direction of fluid swipes matches the direction of scrolling and as
such for NSEventTypeSwipe events gestureAmount is inverted. However, for
some uses of NSEventScrollWheel and NSEventTypeSwipe events, the behavior
should not respect the user preference. This method allows you to determine
when the event has been inverted and compensate by multiplying -1 if
needed.

So I propose V1 of my patch to address this.

This patch adds an extra property to the SDL_MouseWheelEvent that denotes
if natural scrolling has been enabled by the user. It also reverses the
directions by default for OS X so all scroll events are consistent across
all platforms and “natural” settings… Thus if you the developer wish to
have the natural feel the user requested you can simply multiply
(event.wheel.y * event.wheel.natural) and get the corrected direction.

The data is passed via the event as the user CAN change the setting while
your application is running. Also the setting can be set differently based
on the input device… e.g. a mouse have it off, but a trackpad have it on.
Thus a single function SDL_IsMouseWheelInverted() just doesn’t work
cleanly.

I also chose to make event.wheel.natural either 1 or -1 so a simple
multiplication can apply the user preference easily.

Comments on the event field name and other choices are welcome.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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?

Jonny D

That’s really the thing I wanted the MOST feedback on:) Renaming the field to natural_direction_multiplier does make more sense. does it also make sense to default it to normal 100% of the time? (e.g. pre invert the natural motion?)On Feb 25, 2014, at 10:17 PM, Sam Lantinga wrote:

I like the patch in general. I think you may be too clever with the multiplication of the value to get the natural motion. If you want to keep that semantic maybe you can rename it something more clear like “natural_motion_multiplier” or “natural_direction_multiplier”.

On Tue, Feb 25, 2014 at 6:43 PM, Edward Rudd <@Edward_Rudd> wrote:
So, Apple has created this “lovely” behavior on Mac OS X 10.7+ called natural scrolling (or unnatural depending on who you are). At least Apple did make a method to check if the user requested natural scrolling…

One of the games I’m updating for a customer to SDL2 explicitly checked for this “flag” in the mouse scroll events so they could negate it if set. As there are times (especially in games) where you do not want the “natural” feel in certain parts of your game…But other ares you do. and Apple’s documentations even accounted for that.

(From the Apple documentation for NSEvent )

The direction of fluid swipes matches the direction of scrolling and as such for NSEventTypeSwipe events gestureAmount is inverted. However, for some uses of NSEventScrollWheel and NSEventTypeSwipe events, the behavior should not respect the user preference. This method allows you to determine when the event has been inverted and compensate by multiplying -1 if needed.

So I propose V1 of my patch to address this.

This patch adds an extra property to the SDL_MouseWheelEvent that denotes if natural scrolling has been enabled by the user. It also reverses the directions by default for OS X so all scroll events are consistent across all platforms and “natural” settings… Thus if you the developer wish to have the natural feel the user requested you can simply multiply (event.wheel.y * event.wheel.natural) and get the corrected direction.

The data is passed via the event as the user CAN change the setting while your application is running. Also the setting can be set differently based on the input device… e.g. a mouse have it off, but a trackpad have it on. Thus a single function SDL_IsMouseWheelInverted() just doesn’t work cleanly.

I also chose to make event.wheel.natural either 1 or -1 so a simple multiplication can apply the user preference easily.

Comments on the event field name and other choices are welcome.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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?

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

This page summarizes the ones I’ve found…

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.On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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.

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.

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).

Thanks,
EricOn 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

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?

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
SDL at lists.libsdl.org
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…

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.On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:
From my experience, most of those have been features of mouse drivers, not

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think so, at least in the context of games.On Wed, Feb 26, 2014 at 6:51 AM, Edward Rudd wrote:

That’s really the thing I wanted the MOST feedback on:) Renaming the
field to natural_direction_multiplier does make more sense. does it also
make sense to default it to normal 100% of the time? (e.g. pre invert the
natural motion?)

On Feb 25, 2014, at 10:17 PM, Sam Lantinga <@slouken> wrote:

I like the patch in general. I think you may be too clever with the
multiplication of the value to get the natural motion. If you want to keep
that semantic maybe you can rename it something more clear like
"natural_motion_multiplier" or “natural_direction_multiplier”.

On Tue, Feb 25, 2014 at 6:43 PM, Edward Rudd wrote:

So, Apple has created this “lovely” behavior on Mac OS X 10.7+ called
natural scrolling (or unnatural depending on who you are). At least Apple
did make a method to check if the user requested natural scrolling…

One of the games I’m updating for a customer to SDL2 explicitly checked
for this “flag” in the mouse scroll events so they could negate it if set.
As there are times (especially in games) where you do not want the
"natural" feel in certain parts of your game…But other ares you do. and
Apple’s documentations even accounted for that.

(From the Apple documentation for NSEvent )

The direction of fluid swipes matches the direction of scrolling and as
such for NSEventTypeSwipe events gestureAmount is inverted. However, for
some uses of NSEventScrollWheel and NSEventTypeSwipe events, the behavior
should not respect the user preference. This method allows you to determine
when the event has been inverted and compensate by multiplying -1 if
needed.

So I propose V1 of my patch to address this.

This patch adds an extra property to the SDL_MouseWheelEvent that denotes
if natural scrolling has been enabled by the user. It also reverses the
directions by default for OS X so all scroll events are consistent across
all platforms and “natural” settings… Thus if you the developer wish to
have the natural feel the user requested you can simply multiply
(event.wheel.y * event.wheel.natural) and get the corrected direction.

The data is passed via the event as the user CAN change the setting while
your application is running. Also the setting can be set differently based
on the input device… e.g. a mouse have it off, but a trackpad have it on.
Thus a single function SDL_IsMouseWheelInverted() just doesn’t work
cleanly.

I also chose to make event.wheel.natural either 1 or -1 so a simple
multiplication can apply the user preference easily.

Comments on the event field name and other choices are welcome.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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?

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
SDL at lists.libsdl.org
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…

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.

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

Thanks,
EricOn 2/26/14, Edward Rudd wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing <@Eric_Wing> wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:
From my experience, most of those have been features of mouse drivers,

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

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?

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
SDL at lists.libsdl.org
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…

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.

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.On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:
From my experience, most of those have been features of mouse drivers,

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:

On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

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 <@Edward_Rudd> wrote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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-7906On Mar 1, 2014, at 17:42, Edward Rudd <@Edward_Rudd> wrote:

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:

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 <@Edward_Rudd> wrote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

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:

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:

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 http://outoforder.cc/
Skype: outoforder_cc
317-366-7906

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

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 <@slouken> wrote:

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:

On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn <grimfang4 at gmail.com wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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:

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 <@Edward_Rudd> wrote:
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:

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:

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 <@Edward_Rudd> wrote:

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:

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 <@Edward_Rudd> wrote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Looks good, go ahead and push it.

Thanks!On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd wrote:

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 <@slouken> wrote:

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:

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:

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:

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 http://outoforder.cc/
Skype: outoforder_cc
317-366-7906

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

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 <@slouken> wrote:

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:

On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn < grimfang4 at gmail.com> wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It?s pushed… and all the builds are passing now.

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-366-7906On Dec 2, 2014, at 3:03 AM, Sam Lantinga wrote:

Looks good, go ahead and push it.

Thanks!

On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd <@Edward_Rudd> wrote:
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:

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 <@Edward_Rudd> wrote:
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:

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:

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 <@Edward_Rudd> wrote:

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:

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 <@Edward_Rudd> wrote:
On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd <@Edward_Rudd> wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Great, thanks!On Wed, Dec 3, 2014 at 8:10 AM, Edward Rudd wrote:

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 <@slouken> wrote:

Looks good, go ahead and push it.

Thanks!

On Mon, Dec 1, 2014 at 7:31 AM, Edward Rudd wrote:

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 <@slouken> wrote:

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:

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:

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:

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 http://outoforder.cc/
Skype: outoforder_cc
317-366-7906

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

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 <@slouken> wrote:

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:

On Feb 27, 2014, at 12:02 AM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 26, 2014, at 6:05 PM, Eric Wing wrote:

On 2/26/14, Edward Rudd wrote:

On Feb 25, 2014, at 10:57 PM, Jonathan Dearborn < grimfang4 at gmail.com> wrote:

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
SDL at lists.libsdl.org
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…

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org