keyboard events and numlock

Want to put down some semi-official words about the design of the API around keyboard event handling, specifically motivated by the case of dealing with NumLock, motivated by (#334 #342 #329).

tl;dr: our API should be an evolving subset of the w3c KeyboardEvent API. I say "evolving subset" simply because it's a big API that tries to cover everything, and it's fine for us to do things on a more "as needed" basis. For instance, I think it is totally reasonable if we don't handle scroll lock or fn right now, and we can revisit if someone needs them.

NumLock

NumLock (numlock from here on out) doesn't really exist conceptually on macOS; essentially on the mac the number pad is always in number mode.

On platforms that do support numlock, the KeyCode sent should be the code with numlock applied. So the same key will send different keycodes depending on whether or not numlock is active.

There should be an additional flag in KeyModifiers that indicates whether numlock is active.

On macOS, this should be true any time a numpad key is pressed. On other platforms, this should be true if numlock is currently enabled.

'Unknown' keycodes

we have a catchall in the KeyCode enum for 'unknown' keycodes. This has two purposes: it lets us know what keys we need to go and add KeyCode members for, and it provides a last-resort mechanism for special cases where someone might want to handle some obscure media key or similar that we aren't handling.

experimenting

When dealing with this stuff, I think it's very helpful to play around with tools like the w3c key event viewer. It would actually be very useful for us to create something like this of our own, for manual testing.

cc @ratmice

Start by reviewing the existing KeyCode and KeyModifiers API and the related issues #334, #342, and #329. Use the W3C key event viewer to compare platform behavior, then define the intended API and manual-testing expectations for NumLock and unknown keycodes.