Bug 595 - NEWT event propagation to Jinput
Summary: NEWT event propagation to Jinput
Alias: None
Product: Newt
Classification: JogAmp
Component: core (show other bugs)
Version: tbd
Hardware: All all
: P5 enhancement
Assignee: Sven Gothel
Depends on: 814
Blocks: 592
  Show dependency treegraph
Reported: 2012-06-21 23:35 CEST by Sven Gothel
Modified: 2019-03-29 14:11 CET (History)
2 users (show)

See Also:
SCM Refs:
Workaround: ---

First draft with the structure of the new classes (19.69 KB, application/vnd.oasis.opendocument.text)
2013-02-24 23:32 CET, Julien Gouesse

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2012-06-21 23:35:06 CEST

Comment 1 Julien Gouesse 2013-01-07 01:41:27 CET
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.
Comment 2 Julien Gouesse 2013-01-07 20:39:26 CET
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.
Comment 3 Julien Gouesse 2013-02-23 12:34:29 CET
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)
Comment 4 Julien Gouesse 2013-02-23 13:12:58 CET
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).
Comment 5 Julien Gouesse 2013-02-23 13:24:38 CET
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.
Comment 6 Julien Gouesse 2013-02-23 13:36:26 CET
Maybe point-of-view controls and sliders can be treated as a particular case of axis.
Comment 7 Julien Gouesse 2013-02-23 14:20:39 CET
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.
Comment 8 Julien Gouesse 2013-02-24 23:32:51 CET
Created attachment 413 [details]
First draft with the structure of the new classes