WAI
Status Update
Comments
si...@google.com <si...@google.com> #2
I don't think this falls under pointer input so this is simply less tied to the area I've been focusing on. I think this should be considered open for anyone else to start working on. I think the two main areas of work for keyboard input are building out the equivalent of focusableInTouchMode and routing keyboard input events to the appropriate node/modifier.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
si...@google.com <si...@google.com> #3
Hey Shep, thanks for the info.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
si...@google.com <si...@google.com> #4
I don't think this is/should be within Semantics's domain. Hardware keyboard input should, as far as I know, follow the same path as (and is, as far as I understand it, indistinguishable from) soft keyboard input (in fact, Gboard actually interacts with hardware keyboards).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
ma...@gmail.com <ma...@gmail.com> #5
Ah, I based on Siyamed's comment, this bug is intended to track the work necessary to handle keyboard events that aren't related to IME. (like menu shortcuts). I'm not sure what is needed here.
Description
Performance regression was expected especially for shorter text.
However the jump for 32 char count is %50 (600 to 900)
Previously measured expected value was 10%
creating the ticket to check the dashboard in detail.