Thanks for your reply.
> * it's not clear to me that starting with a separate crate makes sense. > It might be less work to prototype all of it inside Servo first. The prototyping inside servo can definitely be done without a separate crate but if servo "ports" like glutin want to provide rich keyboard input information it will be useful to share the type definitions with them and create a separate crate to avoid duplicating work and avoiding (complex) type conversions. > * what is the benefit to glutin if it shares this web-based input model? Glutin aims to be a cross-platform crate that abstracts away from operating system input models. In this regard it is similiar to web technologies wanting to be portable and and yet powerful. If Glutin wants its users to be able to use key attribute values (currently ASCII only with VirtualKeyCode enum), access the physical location of a key, get complete modifier information and allow the creation of text editors (ReceivedCharacter event) with few differences across platforms its API will be similiar to the one described in UI Events. In this case it is sensible to base Glutins API on the web KeyboardEvent. It avoids the need for extensive research on keyboards, provides common identifiers and types also writing documentation and teaching it will be easier since consumers of the API can be pointed to the web specification. If Glutin does not intend to offer platform independent keyboard events but either provide platform specific information or only support US keyboards a web-based input model would not be wanted. In this case either servo needs to provide the mapping of device specific events to web events or if not possible use a different backend. In conclusion if glutin wants to provide a high-level but powerful API to keyboard input that is useful to a wide range of applications the UI Events specification is a good model. > * it is difficult to figure out when it is correct to dispatch the > various DOM events (keydown, keypress, keyup). Any proposal to change > how keyboard input works should describe when those events will occur > and what key information will be available at that point. To be honest I have not thought a lot about how to dispatch the events. I planned to keep doing what servo is currently doing for keydown and keyup events. Then I want to introduce the character event that is created between the two key events and updates input and textarea elements. While both key events hold information about the key pressed the character event only knows the character that should be inserted into the input or textarea but not from where it originated. It should be noted that servo lacks BeforeInputEvent and InputEvent, for this reason dispatching events in the right order should be easier then in a complete browser. Supporting these two events is a separate issue I think but if you disagree I can also try to draft a proposal for dispatching all input related events in servo. Cheers, Pyfisch _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
