Bug 413

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