Atom really needs a KeyboardEvent.key implementation

[natha...@gmail.com]

Rick Byers encouraged me to communicate about this on the mailing list at the Chrome Dev Summit.

In Atom, we use a keydown event handler to match sequences of keystrokes against key bindings. The problem is that on international keyboard layouts, we have a really hard time mapping these events to user intents for characters that require modifiers.

For example, on a German keyboard, `AltGr-Q` is used to insert an `@` character. However, the `keyIdentifier` and `code` properties don't indicate the `@` character and instead report `Q` as having been pressed.

From my understanding of the spec, it seems like the `KeyboardEvent.key` property could be our solution here. It would apply any modifiers that actually influence the printable character up-front based on the configured layout, making it much easier for us to match events to key bindings in a universal way.

1) Am I correct that this is the feature we're looking for?
2) If so, can I chirp for a worm here, and talk anyone on the Chrome team into proceeding with an implementation?

Thanks for your time!

[nat...@github.com]

Argh, posted on my personal account. Subscribing with my GitHub account.

[Dave Tapuska]

Zes (err got to switch my german layout back to english). Yes Nathan you are correct.

If you have a dev chrome build on linux; give it a try here: http://nonan.jp/keyevent/input.html by enabling the experimental web platform features flag.

Seq No.	Event Type	keyCode (e.key)	keyCode (e.keyCode)	Code (e.code)	charCode (e.charCode)	location	Alt	AltGraph	Caps Lock	Control	Fn	Meta	NumLock	Scroll	Shift	SymbolLock	OS	keyIdentifier
4	keydown	AltGraph	225	AltRight	0	2	false	false	false	false	false	false	true	false	false	false	false	U+00E1
5	keydown	@	81	KeyQ	0	0	false	true	false	false	false	false	true	false	false	false	false	U+0051
6	keypress	@	64	KeyQ	64	0	false	true	false	false	false	false	true	false	false	false	false	U+0040
7	keyup	@	81	KeyQ	0	0	false	true	false	false	false	false	true	false	false	false	false	U+0051
8	keyup	AltGraph	225	AltRight	0	2	false	true	false	false	false	false	true	false	false	false	false	U+00E1

crbug.com/227231

The bug is mainly blocked on me writing a windows implementation for dead key handling. The Windows platform doesn't have the same primitives that the the other OS implementations have and we do have some issues because accessing APIs that we'd like to use change the active IME buffer causing input issues.

We are proceeding with an implementation and the original goal was M48; but that got pushed out because of the complexity that was discovered with Windows. I'm not sure if I'll get to it in M49; but if we don't make that it shouldn't be that far off I just need to get some cycles on Windows dev to fix it.

In M48 you should see the AltGraph modifier though; I don't know if that is of any use but it should tell that you are on an international keyboard. (On Windows; Ctrl will likely be seen as depressed as well because of weirdness how the OS conveys the AltGr depression which we also have to figure out if we can fix)

dave.

--
You received this message because you are subscribed to the Google Groups "input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.