The documentation for setComposingRegion states explicitly
that it does not move the cursor. This is just a bug.
This does not have any ill effects right now, but it will have
in later changes if not fixed.
As for the selection handling, the specific test that this code
removes used to serve a purpose, but it does not any more because
the code using the value has been much sanitized. Now the variable
can just take the obvious value, and become so self-explanatory
that the comments are unnecessary.
Change-Id: I548d899b38776bd3ab5f5361aab0d89d98f12e73
This cuts the time spent in computeNearestNeigbors by
a factor of 6 to 20, with an average at about 8.
This method representing about 25% of the total time
spent when switching keyboards, this change is a
20% improvement in layout switching time.
Bug: 8689779
Change-Id: Icb465f6010b317c7156057891c3341e51a198688
As a preparation to show "system default" in the settings. LatinIME
can't know the actual system default value.
Bug: 9468462
Change-Id: I0b7898d1ca29ded7a619dd636d2ad16eb0db292e
This will spare a lot of IPC for Latin IME at the cost of very little
retained memory.
This improves the loading by potentially a lot - between 15 and 30%
when the layout is cached (which should now be the case almost every
time), and half that if it's not. More importantly, it makes the
load time less sensitive to high device load, which is one of the
sore points.
Bug: 8689779
Change-Id: I2e07736f1a92c38eed0e203bc690761a181da8b9
If the logger feedback screen is up and the user hits the home button or the
keyboard otherwise closes, the system won't let the user enter feedback again,
because it is waiting for the user to finish the first one.
With this change, the state associated with the feedback screen is
cleared when the user closes the keyboard.
b/9398772
Change-Id: I832a82793ad42e31b6b3fdb04fabcea75facde7d
In setup wizard, InputMethodManager may not be able to be aware that
this IME is installed, especially just after the IME is installed via
GooglePlay app and hit the open button on the app to launch the setup
wizard.
Bug: 9299618
Change-Id: I00c8544178b41074253d49ae9481996ec56593d2
This is a bit of a shot in the dark, as I really don't see how this
can happen, but this should fix it in the correct way no matter
how it's actually happening.
Bug: 9301836
Change-Id: I472865b7a78883942c9fd46773238c23788674f8
This change utilizes the no panel auto more key feature to implement
long press shift key for shift lock.
Change-Id: I3995d25dc35aea3c67b5aa29299815462eff9cad
Now that separators are put into their own LogUnits, they must be handled
when going through a revert.
Bug: 9088919
Change-Id: Ibebd0752bb2fa38d74ac96001d63070dd419cee3
A LogUnit is only uncommitted if the LogUnit's word matches what is
expected. But a LogUnit never stores numbers, only scrubbed words that
replace numbers with a special character. So when uncommitting, the
text from the TextView must also be scrubbed for the comparison to pass
correctly.
Bug: 9088919
Change-Id: I9b56f10afce6d0cc84eb9ead3b9a9b1e061ae39c
Now that separators have their own LogUnits, they must be uncommitted
from the LogBuffer when backspacing over them.
Bug: 9088919
Change-Id: Ib36cc94939b93abe18850a06bced17caf8aaa5b9
The period-generating double-space adds an extra LogUnit --
it must be removed when reverting.
Bug: 9088919
Change-Id: Ic148f40b4030a9b4a0651029bda87f7b94a52252
Currently when the user reverts a batch input, a LogUnit is uncommitted
from the LogBuffer. It should not be, because the LogUnit containing the
batch input is never committed in the first place (it is only committed
to the LogBuffer when a key is pressed or a new batch input is entered).
Bug: 9088919
Change-Id: I323af453ce082437a663ccae977b21b775a964bc
It turns out giving them in the right order is not enough, you
also have to actually give them a numeric priority.
Bug: 9165928
Change-Id: I2ecff38f65b70746feeeeb0ed2cc86a586a35363
This should be done in onFinishInput rather than onFinishInputView
but for an unknown reason onFinishInput never comes.
Bug: 9113167
Change-Id: Iafb40846a3ed8fad78bfc160d17cd431f81fe891
The default implementation for preferences refuses to
cache the views for custom preferences at all. We can
do it, but the system won't do it for us, so this does it.
This makes the screen scrolling smooth again.
Incidentally it also fixes the bug where the button may
not animate on the first element.
Bug: 8882722
Bug: 8883108
Change-Id: I9b2306ac4bf93761a808ebfee3477a65f017cddf
This change renames containsCorrection to avoid confusion with
CorrectionInfo, and to better clarify its meaning.
Change-Id: I5d8f8e2b03133c15a60d4e8b0f395cda1fff5447
