Posted by Sven Gothel on Oct 10, 2012; 12:56pm
URL: https://forum.jogamp.org/Mouse-Button-Modifiers-Lost-In-Newt-mouseDragged-Events-tp4026456p4026465.html

On 10/10/2012 02:02 PM, rhatcher [via jogamp] wrote:
> Heh.  Your response made me laugh.  Have some coffee!
good and the coffe is hot :)

>
> The bottom line summary is that the NEWT events aren't telling the whole story
> about the mouse button state during mouseDragged and probably mouseMoved too,
> at least with JDK 7u7.  The reason appears to be because a) AWT's getButton()
> method doesn't provide button info for those events (who knows why), and b)
> NEWT's translation of modifier flags only picks up two of the buttons by
> happenstance due to their association with the META and ALT masks.

Again: We seem to talk about AWT -> NEWT event translation ?
Ok, your writup targets AWT -> NEWT event translation
as implemented in AWTNewtEventFactory and used e.g. in
  AWTMouseAdapter, AWTKeyAdapter, AWTWindowAdapter

These adapters are being used e.g. for:
  - Using platform agnostic NEWT events even w/ AWT UI elements

  - NewtCanvasAWT:
      - AWTWindowAdapter: All types for AWT state notifications
      - AWTMouseAdapter, AWTKeyAdapter: NEWT offscreen only (OSX, ..)

So you claim that the resulting NEWT events
from AWT mouse-dragging and AWT mouse-moving are incomplete
in regards to the modifier bits.

This is _not_ regards native NEWT events.

.. now we can go on :)

>
> It is odd that this hasn't been seen before, so perhaps it works differently
> in older versions of the AWT.

Meaning you didn't test against JDK6 ?

TBH I haven't tested modifier bits a lot,
especially not the AWT translated ones
- hence there is no unit test for it yet.

>
> We do our own builds routinely and will of course be happy to submit a change
> for consideration.  The biggest issue we have is that we aren't set up to test
> these changes across a wide variety of platforms; really just Linux, and a
> relatively old version at that.  So... you will need to consider any such
> changes as "suggestions" much like we did the X11 screen issue a few weeks ago
> and adjust as you see fit.

Sounds great.
Well, the platform problem will be easily solved,
if you create unit tests w/ your changes (there is no other way anyways to
commit).
Then our next Jenkins build will show you the results, voila.
Ofc .. given that the same tests have passed at least on one platform :)

>
> A couple questions/clarifications:
>
> 1) So for now the process for submission of patches for less familiar persons
> such as our group will be to attach modified code in Bugzilla and avoid direct
> commits.  
No way - sorry.

I really don't wanne keep track of emails and attachments,
that would be too expensive - thats why we do have git/bugzilla etc.
Have you noted the nice SCM Ref field in our bugzilla DB ?
All fixed bugs can be tracked back to commits.

And I really can use the time better like answering emails here :)

> Obviously it is important to maintain some order in the code base
> and avoid a free-for-all, so somebody on your end still needs to approve such
> changes.

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)

Again - you should provide unit tests, especially for new features.
Even though in the very past we didn't do it this way,
since around later 2009 we do unit test a lot.
Only this way a feature and sane behavior can be guaranteed.

>
> 2) In your ant build infrastructure, is there a magic property somewhere that
> will turn on debug info (locals, line numbers, etc) across the board for
> gluegen, jogl, and joal?  Seems like the last time I was through some of this
> code in the debugger some of that info was missing.

You mean to have the compiler/linker leave/produce the debug info ?
Yes there is (from jogl/scripts/make.jogl.all.linux-x86_64.sh):
#    -Dc.compiler.debug=true \
#    -Djavacdebug="true" \
#    -Djavacdebuglevel="source,lines,vars" \

~Sven