Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • trie-js-dumping protected
  • hitbox-boosting protected
  • model-metadata protected
  • lm-2-finetuning-whisperggml protected
  • lm-2-finetuning protected
  • lm-2 protected
  • language_model_experiments protected
  • 0.1.24.2 protected
  • 0.1.24.2-rc1 protected
  • 0.1.24.1 protected
  • 0.1.24.1-rc1 protected
  • 0.1.24 protected
  • 0.1.24-rc1 protected
  • 0.1.23.2 protected
  • 0.1.23.1 protected
  • 0.1.23 protected
  • 0.1.22 protected
  • 0.1.21 protected
  • 0.1.20 protected
  • 0.1.19 protected
  • 0.1.18 protected
  • 0.1.17 protected
  • 0.1.16 protected
  • 0.1.15 protected
  • 0.1.14.1 protected
  • 0.1.14 protected
  • 0.1.13 protected
28 results
Search by author
  • Any Author
  • Aleksandras Kostarevas Aleksandras Kostarevas alex
  • Dean Dean dean
  • Tom Folbrecht Tom Folbrecht tom
  • sameer sameer sameer
4 authors
  1. Feb 17, 2014
  3. Feb 14, 2014
  5. Feb 13, 2014
    • Jean Chalard's avatar
      Backward compatibility hack : send delete when empty. · 2c488469
      Jean Chalard authored 
      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
      2c488469
    • Jean Chalard's avatar
      Fix a test. · cf03ff02
      Jean Chalard authored 
      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
      cf03ff02
  7. Feb 10, 2014
  9. Feb 06, 2014
  11. Feb 05, 2014
  13. Feb 03, 2014
  15. Jan 29, 2014
  17. Jan 28, 2014
  19. Jan 27, 2014
  21. Jan 23, 2014
  23. Jan 22, 2014
    • Jean Chalard's avatar
      [IL64] Pull up X,Y processing, step 3 · 352286a4
      Jean Chalard authored 
      Bug: 8636060
Change-Id: Ic051e5d5514d270101b0571a2d30e2caa8f85bc1
      352286a4
    • Jean Chalard's avatar
      [IL63] Pull up X,Y processing, step 2 · b8216a4e
      Jean Chalard authored 
      This also fixes the coordinates passed to logOnDelete and
log onSeparator.

Bug: 8636060
Change-Id: I4703d61ad7de76b501adca18df3a69e06450c9a1
      b8216a4e
    • Jean Chalard's avatar
      [IL62] Pull up X,Y processing, step 1 · 2b38b5e8
      Jean Chalard authored 
      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
      2b38b5e8
  25. Jan 20, 2014