Posted by rhatcher on Oct 10, 2012; 5:38pm
URL: https://forum.jogamp.org/Mouse-Button-Modifiers-Lost-In-Newt-mouseDragged-Events-tp4026456p4026466.html

> Again: We seem to talk about AWT -> NEWT event translation?

Sorry I'm not being clear about what's going on; yes, AWT->NEWT event translation is the issue, specifically related to mouse button state.  We have used JOGL 1.1.1a for a long time, but I am new to NEWT and still don't know everything it does yet so my discussion may not be (and obviously is not) complete.


> Meaning you didn't test against JDK6?

Only 7u7 so far, only because that's what we use from day to day.

What is your policy on backward compatibility of JOGL changes?  For example, do changes need to work with 1.4 forward, or 5 forward, or... ?  I have JDKs installed for 1.5.0-22 and 6u33.  Nothing earlier than that currently.


> No way - sorry.

Heh.  However you want to do it is fine of course.  I suppose your git process described below still allows you to decide what you want to keep, so you are protected from noob contributors such as myself - which is all I am concerned about as far as how we submit stuff.


> Pls do it the proper way and use git, then you can send via:
>   - git pull request a'la github
>   - git email patch
>   - git readable repository of your w/ all the sha1 you want me to pull
>     or cherry pick
>   - .. whatever (don't know of any other way)

Sure - though... all I know how to do with git currently is clone your repos, so I probably will mess this up :-).

At this point I have a modified version of AWTNewtEventFactory.java that illustrates at least one way to work around this button/modifier AWT->NEWT translation issue.  It is the only file that changed, so maybe the "git email patch" option is the best way in this case (?).  I will go try to absorb some git and figure out what to do.

The exact form of the unit test is less clear.  In this case the goal is to see if information in the AWT event makes it through to the NEWT event.  So... I guess the most obvious thing to do is construct AWT mouse events representing known button states of interest, run them through AWTNewtEventFactory, and see if the bits set in the resulting NEWT event are correct.


I'd like your input on a few questions before I propose a fix:

1) Generally, do we want NEWT event methods named similarly/identical to AWT event methods to have the same meaning/semantics?  The answer here influences the next question:

2) If a mouse button is held down do we expect someNewtMouseEvent.getButton() to return anything?  The equivalent AWT event method says this will be the button that changed, so I guess it's OK that the NEWT mouse dragged event returns zero from getButton() if the answer to 1) was yes.

3) Do we expect someNewtMouseEvent.getButtonsDown() to return an array containing all currently pressed buttons - and by association someNewtMouseEvent.isButtonDown(someButton) to return true if the indicated button is down - for all mouse events (i.e. including mouse dragged and mouse moved) (?).