Created attachment 153 [details] Source code to demonstrate the bug In a simple com.jogamp.newt.opengl.GLWindow,with a MouseListener listening to mouse events, when the user rolls the mouse, instead of calling mouseWheelMoved(), the methods mousePressed() and mouseReleased() are called. Not critical but still annoying since the method mouseWheelMoved() exists. We expect the method to be called when the event happens...
*** Bug 382 has been marked as a duplicate of this bug. ***
Forgot to mention : i was using jogl-2.0-pre-20100831-linux-i586 on Ubuntu 10.04 with sun jdk
I have the same problem. :-(
I'm using: jogl-2.0-pre-20100611-linux-i586.zip. > java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode) OS: Gentoo GNU linux.
On Monday, October 24, 2011 08:31:26 PM gouessej [via jogamp] wrote: > > Hi > > This bug prevents me from porting the pre-beta version of TUER to JOGL 2.0: > > A mouse pressed event with MouseEvent.BUTTON4 is generated instead of a > mouse wheel event. Sven, do you know how to fix this bug? No, but it rings a bell now. While still @ Sun, we had a 'discussion' whether to use a dedicated 'wheel' event or just representing them as another 'button'. Well, I favored the latter since it's a more generic approach, plus we really cannot tell what-else game-pads may have. Technically it's a button, hence a pass-through button representation is IMHO best. For sure I can be convinced otherwise with good (tech.) arguments. Maybe we can make a checklist here how the wheel is represented on the native platforms: Android: None X11: Usually button4 and button5 Windows: ? OSX: ? If they all use a button representation, I guess it's best to remove the 'wheel' ID. Let me copy paste this email to the bugzilla entry, so we can continue it's discussion there (where it belongs IMHO).
Windows: - WM_MOUSEWHEEL: - x/y position - rotation: (jint) ( GET_WHEEL_DELTA_WPARAM(wParam) / 120.0f ) +++ http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617%28v=vs.85%29.aspx The high-order word indicates the distance the wheel is rotated, expressed in multiples or divisions of WHEEL_DELTA, which is 120. A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user. +++ http://msdn.microsoft.com/en-us/library/ms646273%28v=vs.85%29.aspx If dwFlags contains MOUSEEVENTF_WHEEL, then mouseData specifies the amount of wheel movement. A positive value indicates that the wheel was rotated forward, away from the user; a negative value indicates that the wheel was rotated backward, toward the user. One wheel click is defined as WHEEL_DELTA, which is 120. Windows Vista: If dwFlags contains MOUSEEVENTF_HWHEEL, then dwData specifies the amount of wheel movement. A positive value indicates that the wheel was rotated to the right; a negative value indicates that the wheel was rotated to the left. One wheel click is defined as WHEEL_DELTA, which is 120. +++ So I guess we can assume that the WHEEL_DELTA_PARAM is a positive or negative multiple of 120 ? +++++++++++ X11: mouse button4/5 - we can pass each 'click' as a mouseWheel event. ++++ MacOSX: NSScrollWheel .. w/ some 'complicated' GetDeltaY() code .. +++ Ok .. bottom line I guess is to generate mousewheel events for X11 and we would be done.
X11: (first wheel) BUTTON4 -> SCROLL UP BUTTON5 -> SCROLL DOWN (second wheel) BUTTON6 -> SCROLL LEFT BUTTON7 -> SCROLL RIGHT
As Julien suggested, mapped the 4 X11 button to 2 mouse wheels (See X11Window.java). > 0: UP < 0: DOWN Usually w/ events by 1 .. Updated the MouseEvent API doc as well. See commit: 30c959a4534bc0c6b4718ae65fd4f91d68d6eca6
It's a very good piece of news. Thank you so much.
I reopen this bug as mouseReleased(MouseEvent me) is still called when the mouse scroll is moved. The bug fix should consist in avoiding to generate any MouseEvent on release when the wheel position isn't zero.
I get these logs when using the mouse scroll with the build 577: doMouseEvent: enqueue false, wait false, EVENT_MOUSE_PRESSED, mod 0, pos 631/446, button 5, lastMousePosition: 631 / 446 consumeMouseEvent: event: MouseEvent[EVENT_MOUSE_PRESSED, [I@1917a08/[I@1e2b67c, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511376 d 1ms]]] doMouseEvent: enqueue false, wait false, EVENT_MOUSE_RELEASED, mod 0, pos 631/446, button 5, lastMousePosition: 631 / 446 consumeMouseEvent: event: MouseEvent[EVENT_MOUSE_RELEASED, [I@13ac14d/[I@68d505, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]] doMouseEvent: synthesized MOUSE_CLICKED event: MouseEvent[EVENT_MOUSE_CLICKED, [I@7973e4/[I@1a79071, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]] consumeMouseEvent: event: MouseEvent[EVENT_MOUSE_CLICKED, [I@7973e4/[I@1a79071, button 5, count 1, wheel rotation 0, pointer<1>[-1: 631 / 446 0.0p], InputEvent[modifiers: 0x0, NEWTEvent[sys:false, source:jogamp.newt.driver.x11.X11Window, when:1323211511377 d 0ms]]] You can see that there is no mouse wheel event.
I haven't build on master while pushing out the rc branch to save time, ie not kicking off a master branch build. RC4: https://jogamp.org/chuck/view/RC/job/jogl-RC/44/ sha1 30c959a4534bc0c6b4718ae65fd4f91d68d6eca6 http://jogamp.org/git/?p=jogl.git;a=commit;h=30c959a4534bc0c6b4718ae65fd4f91d68d6eca6 577: https://jogamp.org/chuck/view/fwd/job/jogl/577/ sha1 4856f7800bac165c3770495b77de4a2eabcca46e This one does not contain the mouse wheel tweak ..
I have noticed that a few minutes ago, sorry. I use the release candidate 4 and now it works fine. Thank you very much.