Hi
I’ve noticed that shift-wheel up in Mac OS X produces a wheel down
event (when it should produce a wheel up). Do you think this is easy to
fix? Could somebody point me in the direction of the relevant code
where I might fix it?
Thanks
John
John Knottenbelt wrote:
Hi
I’ve noticed that shift-wheel up in Mac OS X produces a wheel down
event (when it should produce a wheel up). Do you think this is easy
to fix? Could somebody point me in the direction of the relevant code
where I might fix it?
Yes, look at SDL12/src/video/quartz/SDL_QuartzEvents.m around line 900.
I suspect [event deltaY] gets inverted somehow when you press shift…
Stephane
Yes, look at SDL12/src/video/quartz/SDL_QuartzEvents.m around line 900.
I suspect [event deltaY] gets inverted somehow when you press shift…
Ok, looking at the code, I have an hypothesis. I notice that in Mac OS
X, when you hold down shift and scroll-wheel, it does a horizontal
scroll, rather than a vertical one. So my hypothesis is that [ event
delta Y ] will be 0 and hence the if statement will choose the else
branch (wheel down).
What do you think the appropriate fix is? How about making some more
mouse button constants, e.g. SDL_BUTTON_WHEELLEFT and
SDL_BUTTON_WHEELRIGHT?
Thanks
JohnOn 22 Mar 2005, at 21:45, Stephane Marchesin wrote:
John Knottenbelt wrote:
Yes, look at SDL12/src/video/quartz/SDL_QuartzEvents.m around line 900.
I suspect [event deltaY] gets inverted somehow when you press shift…Ok, looking at the code, I have an hypothesis. I notice that in Mac OS
X, when you hold down shift and scroll-wheel, it does a horizontal
scroll, rather than a vertical one. So my hypothesis is that [ event
delta Y ] will be 0 and hence the if statement will choose the else
branch (wheel down).What do you think the appropriate fix is?
Use [even deltaX] when shift is pressed ?
How about making some more mouse button constants, e.g.
SDL_BUTTON_WHEELLEFT and SDL_BUTTON_WHEELRIGHT?
No one will use these if they’re impelmented on jsut one platform.
Stephane> On 22 Mar 2005, at 21:45, Stephane Marchesin wrote:
Stephane Marchesin wrote:
How about making some more mouse button constants, e.g.
SDL_BUTTON_WHEELLEFT and SDL_BUTTON_WHEELRIGHT?No one will use these if they’re impelmented on jsut one platform.
Or we could think of this the other way : they’ll never get impelmented
if you don’t start with one platform 
Stephane
Here is a proposed patch, it makes shift-scrollwheel behave identically
to scrollwheel.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: macosx_shift_scrollwheel.patch
Type: application/octet-stream
Size: 1021 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050323/f15f0eaa/attachment.obj
-------------- next part --------------On 23 Mar 2005, at 01:14, Stephane Marchesin wrote:
Stephane Marchesin wrote:
How about making some more mouse button constants, e.g.
SDL_BUTTON_WHEELLEFT and SDL_BUTTON_WHEELRIGHT?No one will use these if they’re impelmented on jsut one platform.
Or we could think of this the other way : they’ll never get
impelmented if you don’t start with one platformStephane
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
John Knottenbelt wrote:
How about making some more mouse button constants, e.g.
SDL_BUTTON_WHEELLEFT and SDL_BUTTON_WHEELRIGHT?No one will use these if they’re impelmented on jsut one platform.
A few years ago, Apple got a patent on, what basically amounts to a
spherical scroll-wheel. What this is of course is just a track-ball in
the top of a mouse. IMO, the current behavior for SDL should be to swap
the values of X and Y for this event. The reason I say this is because
SDL applications should behave the same on Mac OS X as on any other
platform. That means that until this shift+mousewheel business is
standardized across all/most windowing environments, we have to let the
application developer decide what behavior to implement; ergo, we must
undo what Apple has done, to ensure homogenous behavior on the Apple
platform and others.
In the FUTURE, whenever there actually exist mice with built-in
trackballs, someone will have to choose whether to represent this
second scroll-wheel axis, or to represent the trackball as another
mouse cursor. The latter will probably be the better decision, since
trackballs are already used as mice, and using them is really nothing
like using one, or even two scroll wheels, which generally have much
lower effective control precision than pointer devices.On Mar 22, 2005, at 7:54 PM, Stephane Marchesin wrote:
Donny Viszneki wrote:
In the FUTURE, whenever there actually exist mice with built-in
trackballs, someone will have to choose whether to represent this
second scroll-wheel axis, or to represent the trackball as another
I think the easiest, best, cleanest and most powerful solution would be
to rewrite the event system (for SDL 2.0 ?) to represent everything as a
general device with an id and maybe a short description, and a certain
number of absolute axes (ie axes with an absolute position), relative
axes (axes without an absolute position) and buttons. (There would be
one primary device, which would usually be a mouse but could be
something else on systems without it.)
With this system, a regular three-button mouse with one wheel could be
represented as a device with 3 relative axes (2 for x/y and 1 for
wheel), and 3 buttons. SDL would do the work to represent the mouse
wheel (which is really just 2 extra buttons) as the third relative axis.
-
A mouse with two wheels would have 4 relative axes.
-
A mouse with a trackball on top could have 2 relative axes (for mouse
x/y) and 2 absolute axes (for trackball x/y). -
A 3D-mouse with no wheels could have 3 relative axes and 3 buttons.
-
A joystick could have 2 relative axes (x/y pos), 2 absolute axes
(pressure-sensitive buttons) and 8 buttons. -
A steering wheel could have 1 absolute axis (rotation) and a set of
buttons. -
A tablet could have 6 absolute axes (x/y pos, pressure, x/y tilt,
z-rotation) and 2 buttons (for pen, other tools would have their own id
and number of buttons) -
A keyboard could have no axes and 106 buttons =)
Any game using this system would actually become independent of the
type of the input devices and depend on the capabilities of the
input devices in stead.
Adding general support for things like force feedback would be nice too,
of course. Who knows, maybe someone will release a rumbling keyboard
sometime 
- Gerry
In the FUTURE, whenever there actually exist mice with built-in
trackballs, someone will have to choose whether to represent this second
scroll-wheel axis, or to represent the trackball as another mouse
cursor. The latter will probably be the better decision, since
trackballs are already used as mice, and using them is really nothing
like using one, or even two scroll wheels, which generally have much
lower effective control precision than pointer devices.
Microsoft also sells (and Windows supports) a USB mouse with both
vertical and horizontal wheels, so it’s not necessarily a Mac-specific
thing.
For a fullblown trackball, yeah, it might be worth exposing it as a
second SDL mouse (and the mouse move event in SDL has a field to make
each mouse unique, but I doubt most apps check it).
–ryan.
With this system, a regular three-button mouse with one wheel could be
represented as a device with 3 relative axes (2 for x/y and 1 for
wheel), and 3 buttons. SDL would do the work to represent the mouse
wheel (which is really just 2 extra buttons) as the third relative axis.
I don’t agree…relative and absolute motion on a mouse is different
than a joystick, and while blurring this might reduce entry points, it
doesn’t really gain much over the current API. It’s a good example of
the Joel Spolsky “leaky abstraction” … sometimes a mouse is just a
mouse.
I don’t see anything about either multi-mousewheel mice, or this
hypothetical trackball/mouse combo that can’t be implemented cleanly in
the existing API, either as a new button or mouse input from a different
device ID.
If we get really desperate, we can add a new event type, too.
–ryan.