Posted by
Sven Gothel on
Oct 10, 2012; 9:59pm
URL: https://forum.jogamp.org/Mouse-Button-Modifiers-Lost-In-Newt-mouseDragged-Events-tp4026456p4026469.html
On 10/10/2012 07:38 PM, rhatcher [via jogamp] wrote:
>> 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.
Ok, so one or all of the listed uses cases of my previous post.
>
>
>> 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.
Currently our minimum requirement is 1.6 'core', allowing some flavors
and custom configurations (headless, android, etc).
>
>
>> 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.
Ofc, using DSCM is always a sane & safe process w/ implicit review
before you merge - no central repo for all folks to check-in per se.
Of course .. after your commit #1000 .. I may just press 'merge' :)
>
>
>> 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 :-).
>
Doesn't matter .. b/c when you can give me a git patch or sha1 or your repo
to validate - I am able to track back where your change comes from.
Take your last patch for example, only b/c it was simple enough
and only in one place - it was easy with you given me the point in time etc.
But you know .. usually it's not just that easy .. and there are more
complicated patches.
Many words short sentiment: It will save all our time and nerves
to use out SCM process.
THANK YOU
> 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.
As you wish. Any git way will preserve it's source, i.e. from which sha1 you have branched of. Of course - it must be one of the sha1 I have.
Scenario which would not work, after you have changed file A
in your git repo, you send me another single patch based on your sha1.
This one I cannot grok, since I don't have the whole history.
>
> 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.
AWT Robot .. we already even have one mouse drag use case
TestSwingAWTRobotUsageBeforeJOGLInitBug411.
And a few w/ key types / mouse click ones. Just see call-tree of our AWTRobotUtil class.
>
>
> 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?
We don't need a copy of AWT behavior, especially not if it's not so sane :)
We like to produce the most identical behavior for all platforms,
best example it the KeyEvent class, pls read it's class header doc
and the note for getKeyChar().
This was the result to alias the behavior of all major platforms.
So .. lets try to do the most intuitive and platform neutral.
One thing for sure - we need to document the NEWT event classes.
Thx to your questions and review and to lates attempt to better the
documentation, I cannot agree more that we need more work here!
> The answer here influences
> the next question:
[We speak about NEWT's MouseEvent.EVENT_MOUSE_DRAGGED event, I assume.]
[Please don't be afraid of redundancies in your descriptions ..]
>
> 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.
Well, my intuition would say 'yes the pressed button information
should be delivered with the MouseEvent.EVENT_MOUSE_DRAGGED event.
WindowImpl.java line 2061:
e = new MouseEvent(MouseEvent.EVENT_MOUSE_DRAGGED, this, when,
modifiers, x, y, 1, mouseButtonPressed, 0);
This shows how we actually synthesize the _native_ mouse-drag-event.
Only this way we are able to harmonize the dragging in NEWT for
all platforms.
Maybe we can do the same for the AWT->NEWT event factory, i.e. properly track
the mouse states. One thing comes to mind now is the fact that we follow 2 path
for key/mouse events.
1) Native delivery of details via WindowImpl.doMouseEvent()
2) TK -> NEWT factory, which creates event itself and queues them
(1) does simple state tracking and synthesizes missing event etc
(2) does this not properly and is a diff. code path
Maybe we can change our factories (2) in a way to use method (1),
so it follows same path. What do you think ?
Then we can at least assure (better) that native events
and translated events behave similar.
>
> 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) (?).
We already have solved the multi-touch / multi-pointer problem
with current API, see the [encrypted] doc for
getPointerCount(), getPointerId(int index), getX(int index) .. etc (all w/ index as argument).
Look at unit test: TextureSequenceCubeES2 line 107
Granted .. right now multi-pointer mode is currently only implemented
for Android, see AndroidNewtEventFactory.createMouseEvents(..),
which is very similar to the AWT->NEWT factory.
IMHO we should implement multi-pointer mode for other platforms ASAP,
it's a bug for sure.
I hope my above elaborations give you more insight to the design principles
and ideas (which you might have already found).
So .. I am all up to work w/ you and the whole _TEAM_ here to make
event handling more uniform.
~Sven