The ultimate intent is to make these variables final,
which will allow to move the computing function to the
InputAttributes class.
Change-Id: Ifb1fc7321a19b10d60aa63fa0daaa2708deda2cf
...instead of the hard-to-understand mHasUncommittedTypedChars.
This is possible because now the word composer is actually aware
of commits.
Change-Id: I36b664ce8402a280f801e87b9ebe161f416b0853
Currently, these variables hold the info about the composing
word, or maybe some outdated info, and it's not very clear
which it is. LatinIME is maintaining the freshness info in
a separate boolean, and uses it throughout the code for many,
many things, leading to much confusion.
The idea in grouping this info is, it can be saved in another
instance and restored later. It can be tested against to know
whether there is actually outdated but kept info or not, and
it should allow to straighten out what is actually currently
being typed. Ultimately, it will eliminate the need for
LatinIME to keep track of the status of the info in the
word composer.
Change-Id: I00e2c690f303f8320c9be35590a6df4583e9e456
Also rename the function to reflect better the behavior.
An upcoming change will clean up the remnants
Change-Id: I19bdf0d9e95f62ee749e1f64fe17132c4a5ef0bc
This change introduces KeyboardSet and SubKeyboard XML definitions to
represent a set of keyboard layouts.
Bug: 5002108
Bug: 5679585
Change-Id: Ib6c8d5936187381bb6725c9fe574e93871c01a86
Upon autocorrection, there is visual feedback in the text
view that quickly flashes the background of the text that
just changed. This fixes a race condition that happens
upon autocorrection when typing fast, and that results in
flashing one character too far left (typically, the flashing
area includes the whitespace before the corrected word and
not the last character of the corrected word).
This happens because the call to commitCorrection may
happen before or after the IPC sent by sendKeyChar, but the
arguments are fit only for the case where it arrives first.
Change-Id: I9b5442a665aad5a9bc66cd49228075b9056b37fa
This place is very confusing because a member variable with
a consistent meaning is hijacked for the duration of a function
to mean something else. This is in the way of easy-to-understand
refactoring.
Change-Id: If79bc771950d6bfc0ad5f0e9c51c7ef1dbb45b66
- Stop the word composer from escaping - take a page from the law
of Demeter and only report what is actually needed.
- Fix typos in comments.
- Add a comment for a fishy processing.
- Remove a useless local variable.
Change-Id: I5fa78901cbb5483fc9683bfb7094f47244b85df6
mBestWord has a confusing name - it's actually an auto-correction.
It's cleaner if it lives in the word composer because an
auto-correction should be tied to a specific user input, and
should be reset each time the user input changes to avoid
race conditions.
Change-Id: I718d29395bc747372067e6440e090c6a181994ae
This change moves
* KeyboardSwitcher.getKeyboardId to KeyboardSet.<init> and
KeyboardSet.getKeyboardId.
* KeyboardSwitcher.getF2KeyMode to KeyboardSet.
This is the first step to get rid of shift state from Keyboard.
Bug: 5002108
Bug: 5679585
Change-Id: I2a5a97e5e89277bc606916d45c1afbc8d105d773
Both tests have the same meaning. They should be merged.
Also, if "deleteLast()" deletes more than one char (which
never happens in the current implementation, but it's not
guaranteed), the new code is more correct.
Change-Id: I216df7cd45f4a7d76d1d5d6aa7f8d7f9a6e35ea3
If mHasUncommittedTypedChars is true, then
mWordSavedForAutoCorrectCancellation must always be null, and
spaceState must always be SPACE_STATE_NONE.
Hence, this change is supposed to be very no-op.
Change-Id: I2716f7372d996cc4dec40a4b7ac1ee7f5f4afe91
postUpdateShiftKeyState used to be called also when
mEnteredText is not null => this is a bugfix.
The rest does not change the logic, as posting a message can
be done anywhere within the function with no impact.
Change-Id: I7888797c0778702d64f96701e35b611a55a6a259
If there are no uncommitted chars, we shouldn't enter any of
the tests that follow. We didn't use to, but a change today
made it possible - it should not happen.
There is no point in doing the rest of the tests, they are
sure to fail.
Change-Id: I580dd104aff3585de72a93b38989bfd9713f615b
This also includes a new memorized string with simpler
logic that will allow to remove other members
Change-Id: I0b97243084902e68fcb835b6163c86fef8190ebc
