Some apps depend on the keyboard sending something to them
when the text is empty. This is BROKEN. Your app must not lie
to the keyboard about what is before the cursor. If there is something
to delete, you must not pretend there is not and try to catch some
delete event. This will result in a bad user experience. This will not
work with all IMEs. If your app needs this broken behavior, you're
doing it wrong. Seriously guys, we're not in the era of typewriters
any more, there are touch screens, there are gestures, there is
accessibility, there are many innovative IMEs that don't have
keys. Do *NOT* rely on key events.
This change implements an ugly hack so that these broken apps
may continue half-working with LatinIME. We are very unhappy
about this.
Bug: 12998568
Change-Id: Ia62ae2fbee4fee65b463acf3a79aafcfd0defa1d
This fixes two separate problems:
- The word finds itself with two separate suggestion spans.
This is fine for LatinIME, but it's hard to predict whether it's
fine for other interested parties (other keyboards).
- The test for the blue underline was incorrect.
Change-Id: I3ecc849676851bf25a25238d694adaa956521a26
This change is lacking some comments and break some unit tests.
It needs more work.
This reverts commit 38d31a5e79.
Change-Id: I675854fd0729f2d01b7751e35c6d0117f4f88993
This helps managing the cases where the typed word is not
in the suggestions. This happens during recorrection.
Bug: 8636060
Change-Id: I6784feb793cae96272a7f1d123a0e3bbb8f03143
With this patch, the back-to-the-main-keyboard in the Emoji
palette will be registered as a key-release action instead of
a key-press action, like switch-to-the-emoji-palette in the
main layout. This provides mroe consistent UX when the layout is
switched from the main layout to the Emoji palette then
switched back to the main layout.
BUG: 12464067
Change-Id: Ia0d0185db43234dfcfb7cee2677f3d199fe6ed96
This constant is better located in SuggestedWords.
Or it could be in Constants, that would be fine too.
Bug: 8636060
Change-Id: I3e721bb1e2559f028dce8929eceadfe0478c5924
This is fine because getKey{X,Y} is idempotent for any
non-keyboard coordinate value.
However this makes a net change : the x,y values passed to
LatinImeLoggerUtils.onNonSeparator are now different.
The point is however that they used to be wrong. The logged
values used not to account for the keyboard padding that
is present on tablets, and in the simulating tools we don't
know about that padding so we couldn't use the coordinates.
The catch here is that other calls like LoggerUtils.onSeparator
should follow suit, but this is too big a change to do it at once.
Follow-up changes will fix them too.
Bug: 8636060
Change-Id: If4b3d3cb1ed4b44c35f23e66aba3b5797236bba7
