Should we require `KeyEvent.key_meaning` to be always set?

[Filip Filmar]

Hi folks.

I know the KeyEvent protocol didn't start out this way.  But:

• Not guaranteeing `KeyEvent.key_meaning` means every client needs to apply the US QWERTY keymap on its own anyways.
• A code point could be generated by a key press, but also could be generated without one, as evidenced by the virtual keyboard.

At the moment we install and apply keymaps in every product, but it could be possible to have a

product which does not want more than a single keymap.  Even in that case it seems beneficial

to apply that keymap in a single spot, rather than offload to each runner in turn.

Not sure how radical of a change this would be. Should probably be done carefully as we currently have no automated way to guarantee this as an invariant.

Also, a potential counter-argument is similar to how `required` is thought to not be a good idea in protobufs: something that is "semantically required" today may become obsolete tomorrow.  Maybe the ability to evolve the protocol takes over.

I guess the tradeoff is between (1) evolvability and (2) removing the need for clients to do their own key mapping - it is currently required for them to hedge against the absence of `KeyEvent.key_meaning`, so everyone ends up having to lug a copy of the US QWERTY keymap around.

Thoughts?

F

[Filip Filmar]

On Thu, Nov 18, 2021 at 1:33 PM Filip Filmar <fm...@google.com> wrote:

I guess the tradeoff is between (1) evolvability and (2) removing the need for clients to do their own key mapping - it is currently required for them to hedge against the absence of `KeyEvent.key_meaning`, so everyone ends up having to lug a copy of the US QWERTY keymap around.

I'm looking into whether we can promise something like: "if you are interested in key_meaning, we promise we will only ever run you in a product that sets it."

F