Unified type for buttons across windowing backends

[milibopp]

This is sort of a cross-issue for several projects, so I'll just cc @tomaka @bvssvni explicitly.

I have started to work on an alternative window event handling API that uses carboxyl. I would like to make it backend-agnostic (using Glutin, SDL2 or GLFW) and stumbled upon a slight issue with button types. I would like to expose a single button type in the interface instead being generic over it, as this improves ergonomics and eases switching between backends.

Currently, this crate exposes a button type for Piston, which fits the bill quite nicely. I'd consider mapping events from windowing backends to some public type highly reusable functionality, especially since it usually comes as a giant list of conversions. input seems to be tied to the SDL2 representation and provides a trivial public conversion function. glfw_window::glfw_map_key is not public, however. Is there a specific reason for that? If so, could it be marked unstable instead? I'm merely asking because I'm not sure whether I want to wrap SDL2 and GLFW in terms of a Piston window or on their own. (Although the former may be more convenient I guess…)

Looking at Glutin, it has its own VirtualKeyCode type. This could be replaced or merged with this crate's Key type or, less radically, one could provide another conversion function for Glutin types to this crate's types (maybe in the context of a glutin_window crate).

In any case, I think it would be good to have a common type to represent keys to allow backend-agnostic programming. The same reasoning probably applies to mouse buttons and maybe joysticks and similar input devices.

Thoughts?

[bvssvni]

This was the motivation for starting this library in the first place, so I welcome any suggestions.

We did some testing to make sure all keys were included with the SDL2 back-end, with both Windows and OSX keyboards. We also looked at .NET's implementation for how to name with numerical keys. D0-D9 and NumPad0-NumPad9. The issue used for SDL2 mappings https://github.com/PistonDevelopers/piston/issues/145 I think the enum is OK, but not sure whether we should use SDL2's key codes.

I don't think there is a reason why glfw_window::glfw_map_key is not public.

[milibopp]

I guess, as long as there is no particular reason why a particular mapping is better than the other, it makes sense to just stick to one.

I am just cherry-picking a bit here, as I don't actually need the event handling bits of glfw_window and sdl2_window, as this is basically the part I am replacing with reactive primitives. But having a common representation on the other hand makes sense. For instance, this would allow a library for reading key bindings from a config file that would be independent of the event handling system.

[bvssvni]

The Input structure directly is a bit too low level for many use cases, and it won't be future proof, but having some common structure is better than nothing. piston-event basically just maps Input in a better and more flexible interface that works in hierarchies without depending on propagating the generic constraints. It works with Conrod and AI behavior trees, so I wondered if it would work with FRP as well?

[milibopp]

Well, it's kind of similar. But there are slight semantic differences, so that I can't use it directly. I think the biggest issue is that I differentiate between streams (which have no notion of a current value but are only a sequence of discrete events) and cells (which have a notion of a current value, that can be sampled. in practice they are discretized, but don't necessarily have to be). So, for instance, the mouse positon is handled as a cell, while button events are represented as a stream. All in all, this gives rise to a quite different API.