Separate PnP devices from input structure

[bvssvni]

PnP = Plug and Play

I think some devices belong naturally to the input structure because they are standard devices and have a logical relationship to the window which sends the events:

• Mouse - associate the cursor position with the mouse device
• Keyboard - input text and respond to shortcuts, depending on the active widget
• Multitouch - input from touching the screen, which is associated with the widget

If you think of the input structure in this term it is not user centric, it is simply information from the outside world reacting to the rendered window. There is no information whether the source is coming from one user or more users. The only relationship preserved is that the screen is showing some piece of information which partially causes the input events.

[bvssvni]

Perhaps the most important point here is: What kind of information in the window interacts with the user input? If there is no such interaction, or if the relationship between this information and input is ambiguous, then that piece of information does not belong in the input structure.

[bvssvni]

The optimal structure is depending on

1. What kind of information exists in the rendered window
2. What way the user responds to the information in the rendered window
3. How the application structure model the changed in information to render

[bvssvni]

One solution is to require the application to pay attention to information about connected devices and later interpret the signals in that context. This has some drawbacks:

• It will be hard to debug
• You can't output signals to the device

[bvssvni]

Another solution is to pass Connect(Box<Device>) for each device and use channels to map input from GLFW or SDL2. This has some drawbacks:

• If you are switching loop you no longer keep track of the device in the context
• Each method must use Result to be safe

[bvssvni]

It is obvious that devices are not just read-only, but read and write. This makes them different from keyboard, mouse and multitouch.

[bvssvni]

There is also a distinction between events where order matters, such as button presses, and a continuous signal such as a joystick axis.

[bvssvni]

If we send the whole state on each update, the identity of a device must be preserved between read and write. For every event we receive from a device there must be a way to map back to the identity in the window back-end.

[bvssvni]

This could mean either one of following solutions:

• The id of a device must be a generic parameter in the input structure
• A way to obtain the devices as trait objects from the window back-end

[bvssvni]

We could add an event where we tell the devices are updated but now how to access them. This could work safely because you can only borrow .window from EventIterator while reading the state from the devices.

[bvssvni]

If we are mapping id of a device, we might as well use a user aware identity. See https://github.com/PistonDevelopers/input/issues/57

[bvssvni]

Closing this since we got GenericEvent in the piston-event library.