Closed tomaka closed 10 years ago
Some issues after discussion:
DeviceID
is a String
and must be passed in each event, which is not very efficient.
Suggestions: use another type like (&'static str, u64)
, or use a generic. Using a generic would make the library far more difficult to use because we couldn't force all devices to have the same type for device ID.I would suggest using [u8, 16]
because windows uses GUIDs to identify devices, and GUIDs are 16 bytes long. This is equivalent to u128
but u128
s don't exist.
trait Event { type ElementsIterator = Iterator<(ElementID, f32)>; fn get_elements(&self) -> ElementsIterator; }
but that's not yet possible.To be refactored
Here is a summary of the implementation that I'd propose for this crate.
The library contains two main traits:
Device
andEvent
.Devices
An implementation of this library (for example
gl-init
orglfw-rs
) should provide a way to obtain the list of devices available on the system. The exact way is implementation-specific. For example forglfw
, you could simply add the functionsget_mouses()
,get_keyboards()
andget_gamepads()
.When an object that implements
Device
is also a keyboard, it should also implement theKeyboardDevice
trait, defined in thekeyboard
mod. When a device is also a mouse, it should also implement theMouseDevice
trait, defined in themouse
mod. Same for other kind of devices (gamepad, touch screen, kinect, etc.).These "more precise" traits (
KeyboardDevice
,MouseDevice
, etc.) allows one to get more specific informations: what is the state of a key, what is the position of the cursor on the screen, etc.Defect: there is currently no way to get the type of a device if you don't know it at compile-time. For example if a system can have both keyboards and gamepads, you need to provide
get_keyboards()
andget_gamepads()
instead of justget_devices()
. Associated types will solve this.Events
An implementation should also provide objects which represent input events, and which must implement the
Event
trait. The exact way that events are provided is implementation specific. For example forgl-init
, I would return a list of what happened in the last frame, and one of the things that can happen is an input event. For a more complex implementation you could imaging having a per-deviceSender<Event>
.The
Event
trait allows one to retrieve all the raw informations about an event, ie. which device produced it, which element of the device, and what is the new "value" of the element. But if you want more informations about an event, you can import either theToKeyboardEvent
trait or theToMouseEvent
trait, which allow you to turn, if possible, the event into aKeyboardEvent
or aMouseEvent
.KeyboardEvent
andMouseEvent
are simple enums that are easier to manipulate.Modular
This design is modular. If you want to manipulate raw events, you can just get a list of
Device
s, and receiveEvent
s.If you want to use the keyboard, just use the
input::keyboard
module which contains the definitions forKeyboardDevice
,KeyboardEvent
andToKeyboardEvent
.For the moment I have only added the
keyboard
andmouse
modules, but other modules can be added in the future: kinect, touch screen, wiimote, gamepad, etc. One could even implement its own device type outside of the library, if necessary.