This is already the case for the capital version, and natives
Turkish speakers seem to think it should be the case. An
important reason to make it so is that the Turkish keyboard
has only the dotless i as a "more keys" key, so it's really
hard to type words with a dotless i without this, especially
those with several of them.
Bug: 11519119
Change-Id: I4df2a289783e4eb3c1291b8ad0a2ba5947bf7671
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 change counts all occurrences of each string resource and sort
those in descending order of the occurrence.
Change-Id: I726402157feb0d436a54bd0a7252acd17fd711f9
This change also fixes Bug#12982404; displays the suggestion word
using entire suggestions strip if there is only one suggestion.
Bug: 12564279
Bug: 12982404
Change-Id: I51806b90c3ee34a2072880245d4e33f7be273c8f
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
A replay of that old, horribly hard-to-find bug: we post a
resume message during onStartInputView, so we need
to process it before we start the test. But now the message
is posted with a delay, so we need to wait for the delay...
Change-Id: I843d70e636fa51a68aadbdbbaa73b1711ad7bddd
The motivation of this patch is to make sure a user never feel
haptic feedback when scrolling the Emoji palette. In order to
achieve it, EmojiPageKeyboardView#releaseCurrentKey() should
be called whenever (delayed) keydown events should be canceled.
This patch wires up ViewPager.OnPageChangeListener#onPageScrolled
with EmojiPageKeyboardView#releaseCurrentKey() so that delayed
keydown events will be canceled immediately once the ViewParger
starts scrolling.
BUG: 12964092
Change-Id: Iea8c3e090bb16a8622e6b4a850af2bf963aa77d0
