aboutsummaryrefslogtreecommitdiffstats
path: root/java/src
diff options
context:
space:
mode:
authorJean Chalard <jchalard@google.com>2013-12-27 15:44:29 +0900
committerJean Chalard <jchalard@google.com>2014-01-22 14:41:45 +0900
commit2b38b5e8e60900e45a9d5d591ba6f7f7788e535c (patch)
treeb0ae779e89fcdb8b7494423ae4c90203f89f231d /java/src
parent591580ee8a084d06343b95e409931d05c7269e3c (diff)
downloadlatinime-2b38b5e8e60900e45a9d5d591ba6f7f7788e535c.tar.gz
latinime-2b38b5e8e60900e45a9d5d591ba6f7f7788e535c.tar.xz
latinime-2b38b5e8e60900e45a9d5d591ba6f7f7788e535c.zip
[IL62] Pull up X,Y processing, step 1
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
Diffstat (limited to 'java/src')
-rw-r--r--java/src/com/android/inputmethod/latin/inputlogic/InputLogic.java17
1 files changed, 9 insertions, 8 deletions
diff --git a/java/src/com/android/inputmethod/latin/inputlogic/InputLogic.java b/java/src/com/android/inputmethod/latin/inputlogic/InputLogic.java
index c040ee87d..35dd97a70 100644
--- a/java/src/com/android/inputmethod/latin/inputlogic/InputLogic.java
+++ b/java/src/com/android/inputmethod/latin/inputlogic/InputLogic.java
@@ -475,9 +475,15 @@ public final class InputLogic {
}
final int keyX, keyY;
final Keyboard keyboard = keyboardSwitcher.getKeyboard();
+ final MainKeyboardView mainKeyboardView = keyboardSwitcher.getMainKeyboardView();
+ // TODO: We should reconsider which coordinate system should be used to represent
+ // keyboard event.
if (keyboard != null && keyboard.hasProximityCharsCorrection(codePoint)) {
- keyX = x;
- keyY = y;
+ // x and y include some padding, but everything down the line (especially native
+ // code) needs the coordinates in the keyboard frame.
+ // TODO: move this frame change up
+ keyX = mainKeyboardView.getKeyX(x);
+ keyY = mainKeyboardView.getKeyY(y);
} else {
keyX = Constants.NOT_A_COORDINATE;
keyY = Constants.NOT_A_COORDINATE;
@@ -549,12 +555,7 @@ public final class InputLogic {
resetComposingState(false /* alsoResetLastComposedWord */);
}
if (isComposingWord) {
- final MainKeyboardView mainKeyboardView = keyboardSwitcher.getMainKeyboardView();
- // TODO: We should reconsider which coordinate system should be used to represent
- // keyboard event.
- final int keyX = mainKeyboardView.getKeyX(x);
- final int keyY = mainKeyboardView.getKeyY(y);
- mWordComposer.add(codePoint, keyX, keyY);
+ mWordComposer.add(codePoint, x, y);
// If it's the first letter, make note of auto-caps state
if (mWordComposer.size() == 1) {
// We pass 1 to getPreviousWordForSuggestion because we were not composing a word