This now supports all cases, including cases not supported by
the framework.
Now rebased on top of the right change, and renamed
Change-Id: I7886f0dcbb86cdb4dccec09aa7c52ad339680e04
It's probably cleaner to just pass the events rather than read
them from a transaction, especially when a transaction may be
associated with several events in a chain.
Change-Id: I27830f0f3f3f32fe77ea8b9cad505b7ebee648af
Do away with the didAutoCorrect local variables which are
unnatural to return out of all these functions.
Change-Id: I22024004d2c489de018beff812c2c589bfd8ca32
...otherwise we can't recompute the composition when we
change scripts.
This also fixes when we register that we need to take note
that the current subtype was used. Luckily this is a good
occasion for some cleanup that I've wanted to do for some
time: use InputTransaction for onTextInput (with the goal
to ultimately remove it entirely)
Bug: 15840116
Change-Id: Ie4f4f9157b66b79237eeb3db75535803124d3e19
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
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
