Fix NEWT/AWT WindowClosing Unit Tests ; Review/Cleanup NEWT WindowClosing mechanism
Due to a NEWT WindowClosing event regression cause by NewtCanvasAWT changes a review of our WindowClosing event mechanism was required.
Important cleanups are marked w/ '(*)' below.
I would have preferred to change the 'WindowListener.windowDestroyNotify(WindowEvent)' method to pass a WindowCloseEvent object exposing more information like toolkit or programmatic destruction and passing whether a 'closing' or 'nop' action will be performed based on the WindowClosingMode. For now I postponed this idea .. since it would change the API again, but may reconsider it after merging the Android 'closing' patch.
- InputEvent.consumedTag -> NEWTEvent.consumedTag
- Window - (*) Promote setWindowDestroyNotifyAction(Runnable) to public, former WindowImpl.setHandleDestroyNotify(boolean). Using a Runnable action for WindowImpl.windowDestroyNotify(boolean) allows a setting defined alternative for destroy() and gets rid of [ab]using WindowListener.windowDestroyNotify(WindowEvent) for lifecycle actions. Used in: - GLWindow - GLAutoDrawableDelegate impl.
- WindowImpl - Respect NEWTEvent.consumedTag for WindowEvents as well
- (*) Impl. setHandleDestroyNotify(boolean) (see above)
- (*) destroy() simply sends out pre- and post- destruction Window events, where windowDestroyNotify(boolean) sends out the pre-destruction event if NOP.
- (*) windowDestroyNotify(boolean) is public now, allowing other impl. details to follow proper destruction using handleDestroyNotify Runnable (-> NewtCanvasAWT).
- AWTWindowClosingProtocol: - addClosingListenerOneShot() -> addClosingListener() - calling addClosingListener() at addNotify() - calling removeClosingListener() at removeNotify()
- AWTWindowClosingProtocol ctor taking NOP runnable, allowing to send WindowEvent.EVENT_WINDOW_DESTROY_NOTIFY at WindowClosingMode.DO_NOTHING_ON_CLOSE
- Also fwd windowClosed in window closing fwd'ing.
- NewtCanvasAWT - (*) Utilize AWTWindowClosingProtocol NOP runnable (see above) to fwd closing-NOP event to NEWT
- (*) Unify remove/destroy code in destroyImpl(..) - !removeNotify -> destroy NEWT child programatic or as toolkit event - removeNotify || windowClosing -> destroy jawtWindow
- (*) Remove AWTWindowAdapter/AWTParentWindowAdapter's windowClosingListener, since we utilize AWTWindowClosingProtocol
- DisplayImpl - Adding 'final void dispatchMessage(final NEWTEvent event)' allowing to remove the NEWTEventTask wrapping for no reason in enqueueEvent(..) if on EDT and waiting.
Fix Bug 677: NEWT/Android: Add support for Android's KeyEvent.KEYCODE_BACK
Original author: Eric Brayet <ericb@daysofwonder.com> Revised by: Sven Gothel <sgothel@jausoft.com>
I took the freedom to cleanup the three original patches from https://github.com/Pooouf/jogl.git branch 'bug_677': - 7449d4726633d524a3bb79efffd04cfd0ca25e58 (removed by followup patch!) - 68c739a4f03e46deecdbb71c125b4586aec08d63 (removes previous patch!) - c2813dfc325a1482d18b6fc304e4e483f5633964
Further more I was able to reduce the 'extra' code while utilizing - Window's isKeyboardVisible() and using keyboardVisibilityChanged(false) to update the hidden keyboard state. - Moving the key-handling code to the containing WindowDriver class avoiding passing a reference to the inner view. - Using AndroidNewtEventFactory for NEWT KeyEvent creation
+++
- Handle KeyEvent.KEYCODE_BACK w/ jogamp.newt.driver.android.WindowDriver.MSurfaceView.onKeyPreIme(..): if( soft keyboard is up ) [1] Update keyboard visibility state and return NEWT KeyEvent.VK_KEYBOARD_INVISIBLE; else [2] call WindowImpl.windowDestroyNotify(true)
[3] then cont. processing, i.e. return false;
- Turns out respecting WindowClosingMode might be - too complicated - interfere w/ Android UI behavior
- AndroidNewtEventFactory - createKeyEvent - static - adding boolean param 'inclSysKeys', if true, KEYCODE_BACK and KEYCODE_HOME are mapped
- Unit tests: GearsES2 + MovieCubeActivity0 shows keyboard if pressure > 0.6f - pressure on Android shall be between [0..1], however we have to figure out badly calibrated touchpads/Android device where we could experience pressure > 2.0f !
Due to high fluctuation (lack of normalized) pressure values on Android devices, an option to query the normalized value and access to the current known maximum pressure is required.
MouseEvent: - getMaxPressure() returning the [self calibrated] known maximum pressure
Fix Bug 695: WGLExt.wglChoosePixelFormatARB causes buffer underflow due to a higher reported number of configs than buffer size
"I encountered a case on an NVidia Quadro 3500 fx where the call to WGLExt.wglChoosePixelFormatARB in WindowsWGLGraphicsConfiguration (currently line 355) returns 264 in numFormatsTmp despite 256 being passed in for the maximum number of formats. This results in a buffer underflow on line 368 since pformatsTmp only has 256 values and it's trying to copy 264 values."
Fixed in WindowsWGLGraphicsConfiguration and WindowsPbufferWGLDrawable.