With hardware events, we do have some events that
have both a keycode and a code point, so we need
a better way of distinguishing between auto-insert
keystrokes and others.
Change-Id: Ia23042989b4dca9d3a7d4a4c06bcebdabe324a7a
The event interpreter should intervene later, after decoding.
Decoding should happen first, and then the Event should
be passed to the InputLogic.
For the time being, we will leave the (unused) EventInterpreter
class and its friends, because we'll use them again later.
Bug: 13406701
Change-Id: I7582d486724311e39e6692e606cca50c78800643
The combining framework will be more generic than previously
thought. We don't need to handle dead keys as a special type
of event, as all events can be combined arbitrarily.
Bug: 13406701
Change-Id: I8137fdb186c4d70eaa71808c5a1430b1559db1ae
Essentially this does activate auto-correction with a hardware
keyboard, although a lot of things are still left to implement.
No proximity is used yet which means only missing and excessive
letters are considered. Dead keys are not handled. No combiner
is supported. No suggestions are displayed. Resuming suggestions
does not work correctly with a hardware key (because the view
holds a temporary hardware event 'onKeyPreIme' and the event
from the IME won't be handled until this is handled which won't
happen until after the IME said that it did handle the event).
Bug: 5037589
Change-Id: Idcb5c7b26d56717ed772d53c062362807f11cdae
