Sven's suggestion seems good, we could implement a kind of adapter similar to AWTAdapter. We have to decide which propagation is really useful for us, which test cases we'd like to treat. Several "controllers" should be used to represent the mouse and the keyboard, they would feed JInput with new events. The propagation in the other direction would use the polling to get JInput events (see Controller.poll() and EventQueue.getNextEvent(Event)) to feed NEWT new callback: void buttonPressed(ButtonEvent) void buttonReleased(ButtonEvent) void buttonTyped(ButtonEvent) void axisMoved(AxisEvent) void povMoved(POVEvent) The main problem is the modularity. It would be better not to bind NEWT with JInput too tightly if we found it a bit heavy and if some people simply didn't want to use it. If there are references to events specific to axis, buttons and pov in NEWT, it will be hard to deploy NEWT without JInput. However, the latter has a low footprint.
The focus has to be taken into account, only the focused NEWT window should get the input. Relative and absolute values have to be treated differently too. Buttons are "digital" components in JInput, they can take only 2 values unlike "analog" components. The "typed" events will have to be artificially generated, just right after the release. We may plan to integrate only the native source code allowing to get the polling data and discover controllers in order to reduce the footprint of this feature in NEWT. Moreover, keyboard and mouse support has similar implementations in JInput and NEWT.
There is no need of handling button typed events but slider events were missing. Using a single class of event for joysticks seems preferable but it does not yet include force feedback: void buttonPressed(JoystickEvent) void buttonReleased(JoystickEvent) void sliderMoved(JoystickEvent) void axisMoved(JoystickEvent) void povMoved(JoystickEvent)
I prefer using several subclasses for events: void buttonPressed(JoystickButtonEvent) void buttonReleased(JoystickButtonEvent) void sliderMoved(JoystickSliderEvent) void axisMoved(JoystickAxisEvent) void povMoved(JoystickPovEvent) All these classes are subclasses of com.jogamp.newt.event.JoystickEvent (which is abstract and extends NEWTEvent).
Pov can only take 9 values matching with 9 "directions": - centered - north - south - west - east ... Each slider have an abscissa and an ordinate. Each axis has a single (absolute?) value.
Maybe point-of-view controls and sliders can be treated as a particular case of axis.
A ControllerEnvironmentEvent is fired when a controller is added or removed. ControllerEnvironmentEvent extends ControllerEvent. ControllerEvent keeps a reference on a Controller object that contains the information about a controller. The event model I suggest is entirely event-based unlike the one of JInput that handles environment changes with listeners and the rest with polling.
Created attachment 413 [details] First draft with the structure of the new classes