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
A transaction should always operate with a consistent set
of settings. It's better to have it reference them than to
always pass them along.
Bug: 8636060
Change-Id: I3c642dfea6be30712fc6cbb279c64f3185895791
This unifies the software and hardware keyboard code
under a single decision process that works.
Bug: 8129303
Bug: 8152758
Change-Id: I7574c563d5f957d57bfe62fe5e3eec59a519d335
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
Jean Chalard
Ken Wakasa