Should KeyMeaning ever be set on KeyEventType::Released?

[Filip Filmar]

Hi folks.

So, should KeyMeaning in a KeyboardEvent ever be set on KeyEventType::Released?

This came up in the context of implementing dead keys support.  A KeyMeaning containing

a code point for an accented character (for example, Ê - E circumflex) is emitted once a key press on the circumflex dead key is detected, followed by SHIFT, then E.

Do we ever want to emit a corresponding release of an E circumflex? I would think that most clients would either be interested in the USB HID of the keys they are pressing, or in just that instant when the actuated keys amount to the desired key meaning.

Relatedly, it seems that it would be quite involved to detect when to emit a "key meaning release", so if the answer to the above is "no", that would also amount to a much simpler implementation.

Relatedly, if the answer is "no", then we should also probably stop filling out key meanings on key releases -- which we do today.

Thoughts?

F

[Alice Neels]

I think "no" is the simplest answer right now. Let's proceed with that assumption? We can change it in the future if we find a use-case, but it seems more likely that we'll move a lot of functionality to Konstantin's API before it becomes a big issue.

-A

--
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/CAGEh6biSHw6piqvgDFRjJpGMgGHGmgWQnZ%3DfwBNGmopUrOcH%3Dw%40mail.gmail.com.

[Mukesh Agrawal]

+Kevin Marshall do you know if we'd cause any trouble on the Chrome side of things, if we stopped setting KeyMeaning on Released events (from the virtual keyboard)?

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/ui-input-dev/CAKzuf01DApXjE-A%3DXkYYTipuS6MahuBWwfOaPZ5D%3DtWSTyUDTw%40mail.gmail.com.

[Filip Filmar]

On Fri, Nov 5, 2021 at 11:16 AM Mukesh Agrawal <qui...@google.com> wrote:

+Kevin Marshall do you know if we'd cause any trouble on the Chrome side of things, if we stopped setting KeyMeaning on Released events (from the virtual keyboard)?

On Fri, Nov 5, 2021 at 9:41 AM 'Alice Neels' via ui-input-dev <ui-inp...@fuchsia.dev> wrote:

I think "no" is the simplest answer right now. Let's proceed with that assumption? We can change it in the future if we find a use-case, but it seems more likely that we'll move a lot of functionality to Konstantin's API before it becomes a big issue.

In the spirit of "morning is smarter than the evening" I dug a bit more into the dead key implementation, and realized that for correct composition we will need to implement the full state machine for the key presses and releases, rendering this question moot.  With that implementation, it will be possible to maintain the invariant that we currently have, and nothing needs to change regarding the keyboard protocol.

For some background, the reason the full state machine is needed is related to the ability to interleave correctly the key events and the key meanings while composition is in progress.  For example, when a combining character is pressed, we must propagate the key event, while suppressing the key meaning until the time we know which composed character needs to be emitted.  We may find ourselves needing to report a key meaning without a key event, though I think that in the state machine in the link this shouldn't be needed.

In summary, we don't need to consider changing the protocol on KeyEventType::Released just yet.

F