I'm glad someone is thinking about how to improve Servo's current
minimal keyboard input. I have a few thoughts:
* 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.
* what is the benefit to glutin if it shares this web-based input 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.
Cheers,
Josh
On 6/23/17 2:06 PM, Pyfisch wrote:
Hi,
I'd like to improve Servos keyboard support.
At the moment Servo assumes everyone uses US-keyboards and allows only
entering ASCII characters in forms. While KeyboardEvents are supported
they are not created for keys present on international keyboards.
Servo should try to conform to the Keyboard Events from the UI Events
specification. [1] But this is not sufficient to allow entry of accented
and other combined characters with dead keys in input fields. For this
reason I propose to use internal "CharacterEvents" that use the
character sequences provided by the operating system for keyboard input
in addition to the keysyms and scancodes useful for shortcuts and
navigation. It is not really possible to join these two events (as it is
done currently in servo) because they are independent in Windows and
there are cases where it is not possible to associate a key to a
character sequence.
I can think of at least two different ways to approach the problem:
* Extend glutin (or to be more precise winit) to capture more input
information. After winit provides all information necessary to implement
correct keyboard input Servo can make use of it.
* Extend Servo first and only use the information provided by glutin.
This means while servo implements keyboard input embedders will at first
only use a small part of it.
There is currently work done to unfork glutin in servo and to use the
upstream crate. [2] This allows Servo to take advantage of some
improvements for keyboard input inside glutin. Also other projects can
benefit from improvements to glutin if servo gets better keyboard handling.
There is quite some information that needs to be represented about
keyboard inputs. This information needs to be provided be glutin or
other embedders of servo. I would represent it like this:
One, character input, one codepoint at a time. This
`WindowEvent::ReceivedCharacter` in glutin. Joining these characters
together forms a text like in a text editor. All accents, foreign
scripts etc. are preserved. This is also used for input not from a
keyboard but from another inputs like voice or handwriting.
Two, key events. You need to know the "key" which is either a character
like "a", "1", "ß" or it is a name like "Enter". Since the names are a
fixed list they can be represented as an enum with a "Character" variant
for printable keys. These keys are equivalent to keysyms provided by
most platforms. Additionally the web standards has a "code" property
describing the physical location of the key independent from the locale.
Often scancodes can be used to detect these. They can also be
represented as an enum. Of course it needs to be stored if it is a
"keydown" or "keyup" event. Additionally a list of "modifiers" like
"Shift" and "Alt" need to be transmitted alongside the event. This can
be a struct with a lot of boolean fields. All other properties of key
events in JS can be computed from these values.
I propose to place these data structures in a separate crate to be used
by both servo and glutin and possibly other projects wanting to use
keyboard input similar to the web.
To limit the scope of this proposal I do not intend to support
composition events or IMEs.
What is your opinion on this and what can be improved from this proposal?
Cheers,
Pyfisch
[1]: https://www.w3.org/TR/uievents/#events-keyboardevents
[2]: https://github.com/servo/servo/pull/17311
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
