Current KeyEvent API not adequate for dead key support - the easy piece

13 views
Skip to first unread message

Filip Filmar

unread,
Nov 8, 2021, 7:59:01 PM11/8/21
to ui-inp...@fuchsia.dev
Hi folks.

This was a fun discovery while I was working on dead keys support.  It seems to me that we may
need to rework the way the KeyEvent API works, in order to support clients that use it for receiving
key meanings.

Consider what happens when a dead key is pressed on the keyboard.  On the AZERTY keyboard, the circumflex dead key key is located at the position of the '[' key on the US QWERTY keyboard.

What should the input pipeline do when KeyEventType::Pressed comes in? 

We can not withhold the event, as that would break clients that observe KeyEvents.  But if we don't withhold it, we can't fill KeyMeaning either because there isn't one yet - we will get a key meaning once the user types the next character up.  If we defer emitting KeyMeaning, however, 

I thought that clearing KeyMeaning would be enough. But, I was wrong. Our current 
consumers will interpret KeyEvent without a KeyMeaning as if KeyMeaning was filled out based
on US QWERTY.  So you don't get "E circumflex", but rather "open angle brace; then E circumflex."

So, it seems to me that clients interested in key meanings should start requiring KeyMeaning to be
set, always and stop interpreting key as US QWERTY presses.

This also implies that we should start always populating key meaning in KeyEvent, and do it always, no matter whether the keymap handler is installed.  Our spec is currently under-specified in this area, so it doesn't seem like a cardinal sin to firm it up.

Thoughts?

F

Filip Filmar

unread,
Nov 8, 2021, 8:19:46 PM11/8/21
to ui-inp...@fuchsia.dev
On Mon, Nov 8, 2021 at 4:58 PM Filip Filmar <fm...@google.com> wrote:
This was a fun discovery while I was working on dead keys support.  It seems to me that we may
need to rework the way the KeyEvent API works, in order to support clients that use it for receiving
key meanings. [...]

A second discovery, which is less easy to fix: I think we will need the ability to decouple KeyEvent::key from KeyEvent::key_meaning in full. 

That is, we will need the ability to emit a KeyEvent that only has the one, or only the other, and have the semantics of these firmed up.  I think that today in practice we either have the key without the key_meaning, or we have both filled in.  Our spec is not very clear about when either of these situations happens, nor what they mean when they do, implying that anything goes, and that the implementation is the spec.

The principled reason to do this is to decouple the two different communication intentions which we currently bundle together: one, is reporting key events (pressed/released), and another is reporting key-event-based text edits.

A practical reason came up while I was working on the dead key support, specifically some interesting edge cases.  Namely, what should happen if the user presses a dead key, then presses a different dead key while the composition is still in progress? Or, for that matter, any of the other possible interleavings of keypresses which are logically equivalent to that one.  Well one possible answer is that the first dead key press should be output as a diacritic (since it won't ever compose with the other dead key), and then the composition should be restarted with the other dead key.  However, this would require us to report 2 different events, but we only have a budget of 1 event to send out - the KeyEvent corresponding to the second dead key actuation.  If we were allowed to decouple the key press from the key meaning, we could then have reported a key meaning separately, and do the right thing.

Alternatively, of course, we could have the text editing API that handles the above case, yes; but we still must provide key event based text edits, so we need some solution for the above issue. Hence the decoupling proposal.

Thoughts?

F

Filip Filmar

unread,
Nov 8, 2021, 8:46:48 PM11/8/21
to ui-inp...@fuchsia.dev
On Mon, Nov 8, 2021 at 4:58 PM Filip Filmar <fm...@google.com> wrote:
So, it seems to me that clients interested in key meanings should start requiring KeyMeaning to be set, always and stop interpreting key as US QWERTY presses.

KeyMeaning would need to be set at all times when we want to communicate edit events, even in the products where the keymaps are not applied. 

Alice Neels

unread,
Nov 9, 2021, 3:10:10 PM11/9/21
to Filip Filmar, ui-inp...@fuchsia.dev
The long term fix for key meaning has always been to move to a composition API for things like onscreen keyboard. If we do that, does your problem go away?

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "ui-input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ui-input-dev...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/ui-input-dev/CAGEh6bhjkBs5ybFZj5iVWRAZfzckR6C2VjoPKGWb4MFonArJwQ%40mail.gmail.com.

Filip Filmar

unread,
Nov 9, 2021, 3:14:41 PM11/9/21
to Alice Neels, ui-inp...@fuchsia.dev
On Tue, Nov 9, 2021 at 12:10 PM Alice Neels <nee...@google.com> wrote:
The long term fix for key meaning has always been to move to a composition API for things like onscreen keyboard. If we do that, does your problem go away?

 It might go away for consumers that move to the composition API.   It's a new API in which anything is possible.

In the past I think we discussed consumers that won't/can't migrate to the composition API for one reason or another. Such consumers might remain an issue, assuming that there are in fact such customers.

F

Filip Filmar

unread,
Nov 9, 2021, 4:08:04 PM11/9/21
to Alice Neels, ui-inp...@fuchsia.dev
On Tue, Nov 9, 2021 at 12:10 PM Alice Neels <nee...@google.com> wrote:
The long term fix for key meaning has always been to move to a composition API for things like onscreen keyboard. If we do that, does your problem go away?

Good news! It turns out that a key with the meaning of `KeyMeaning::Codepoint(0)` has exactly the separation semantics needed to ensure that default keymaps are not applied.

I don't think this was intentional, but it seems to have that effect on the consumers. I'll allow it. :) (And we should document, and/or make this explicit!)

F

Mukesh Agrawal

unread,
Nov 9, 2021, 4:09:59 PM11/9/21
to Filip Filmar, Alice Neels, ui-inp...@fuchsia.dev
SGTM. 
Reply all
Reply to author
Forward
0 new messages