| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Followup CL that removes some more unused methods and variables.
Change-Id: I4163c7cd017f59d1fd445adb6294fc89dcaafe6e
|
|
|
|
|
|
|
|
|
|
| |
When committing a span after a revert, the offset logic was such that it
split a surrogate unicode pair used to express an emoji.
Checking the last character of the span lets us avoid this problem.
Fix for bug 19255233.
Change-Id: I07d18d9002b5075f7925319dd05962011656c311
|
|
|
|
| |
Change-Id: I059b1062e1d73b2fa439d9d4ee04ff0182795335
|
|
|
|
|
| |
Bug: 18108776
Change-Id: Ia46a4102a0e86e71118ca5e641f9f531998e166b
|
|
|
|
|
|
|
| |
Our intention is to have classes of latinime-common under the common
package as much as we can.
Change-Id: I76efbbbe7bebf1a4aa943715cdff64f91675e20d
|
|
|
|
|
| |
Bug: 18085768
Change-Id: I016bec997787839526ddfc521ebb99d0c7b05189
|
|
|
|
|
|
|
| |
This CL also adds @SuppressWarning("unused" to java-overridable package.
Bug: 18003991
Change-Id: If70527e30654384705d7a814f5efd181d9f539e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL fixes the following compiler warnings.
- Indirect access to static member
- Access to a non-accessible member of an enclosing type
- Parameter assignment
- Method can be static
- Local variable declaration hides another field or variable
- Value of local variable is not used
- Unused import
- Unused private member
- Unnecessary 'else' statement
- Unnecessary declaration of throw exception
- Redundant type arguments
- Missing '@Override' annotation
- Unused '@SuppressWarning' annotations
Bug: 18003991
Change-Id: Icfebe753e53a2cc621848f769d6a3d7ce501ebc7
|
|
|
|
|
| |
Bug: 17958289
Change-Id: I5c9ea668ff75b38c7ddebd767c36a950835c0c9f
|
|
|
|
|
| |
Bug: 17400259
Change-Id: Ib3511afffe1d14662e7dd14611f384689516e664
|
|
|
|
|
| |
Bug: 17130496
Change-Id: I1a3631670c152d9b7667c9c4e08e14c48569eef5
|
|
|
|
|
| |
Bug: 14425059
Change-Id: Id06a71681fa8b5e589e29fba10fe5c1cfed66984
|
|\
| |
| |
| | |
Change-Id: If391cc622367dfb4448c6a5c32b82111d352d86e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this CL, the previously used commit indicator was reverted.
Instead we use the add-to-dictionary indicator only at the moment.
This CL also fixes the indicator position in bidi context.
BUG: 17335734
Change-Id: I5f7cf173ddc30876e2b01320acaff8ba4265edf6
|
|\|
| |
| |
| |
| |
| |
| | |
stop on connectors
* commit '61e7afa6fa98939f9dcb9f7a2ebb5678a51d4201':
Fix a bug where recorrection would stop on connectors
|
| |
| |
| |
| |
| | |
Bug: 16733686
Change-Id: I7a9f79a81e33a1f5bf5f3daf0b78d0f1e4447e7a
|
|/
|
|
|
| |
Change-Id: I623e4ccbc324751eb67ec4bb777e2be5ae2a60d1
Bug: 17418371
|
|
|
|
|
|
|
|
| |
This is a follow up CL for API signature change in
I772c48ff18918e48a81e807b48ff907614485c09
BUG: 17320996
Change-Id: Ic8b6162bda12bf74fae79af212c5d81c400eb9e8
|
|
|
|
|
|
|
|
|
| |
RichInputConnection#requestUpdateCursorAnchorInfo must make
sure to obtain the input connection before calling methods
of it.
BUG: 17299587
Change-Id: I8e0cd473a4cc32583cd47634c227d702f7c69c6c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When CursorAnchorInfo is unavailable, we shouldn't try to show
the commit indicator and set the text highlight color.
With this CL, RichInputConnection can be used to track if the
application responded that it does support CursorAnchorInfo or
not. This result will be taken into consideration when
InputLogic needs to determine whether the commit indicator
should be displayed or not.
Change-Id: I945d70eeb02a7a5f3d9b22459b23d7028508910f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a groundwork for subsequent CLs where we need to
add/remove background color to/from the commited text.
In this CL, we use Spanned#SPAN_COMPOSING so that we can easily
remove such a background color by calling
InputConnection#finishComposingText. To make this operation easy
and realiable, we need to track whether we have specified the
background color to the commited text or not at one place. Here
we use RichInputConnection for this purpose.
Change-Id: I5f9bc4425c5d1b80a719a20e5baf336729ec08d2
|
|
|
|
|
|
|
|
|
|
| |
There is a bug in ICS where the input connection won't take
any writing commands after rotation until the cursor moves.
This fixes it by wiggling the cursor position once before trying
to do anything.
Bug: 16810766
Change-Id: Ib14c70bd0550420cecfa86dea501d13a1a91e296
|
|
|
|
|
| |
Bug: 14425059
Change-Id: Id37022ac6c1545d6845abfbcdb7ed47f0e250eec
|
|
|
|
|
|
|
| |
...also implement the check for Hebrew and Arabic.
Bug: 15840116
Change-Id: Ia6433d7d98038ade64c171be4fe4b3f094111fac
|
|
|
|
|
| |
Bug: 15840116
Change-Id: I545cc9083aa4e2fd7cbbd1fbc02e1e382482db7c
|
|
|
|
|
| |
Bug: 15840116
Change-Id: I1123426fbd9d420c1be64ccc917a5f870e70e6fa
|
|
|
|
|
|
|
| |
This reverts commit 1d300239612591879d535c20ade1f2712048170e that broke the build.
Bug: 15840116
Change-Id: I0a5fa7dea2b418d19df24b2b31ed96bf192d45c0
|
|
|
|
|
| |
Bug: 15840116
Change-Id: Ib3380cfc9d343c6f8953bba03af3801142bc3bdb
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit ba463c9a66f75e8d00f4658e32b763eb54215231 that broke the dicttool build.
Bug: 14425059
Change-Id: Ie1685587104d26e4416624747c97f6087c13388a
|
|\| |
|
| |
| |
| |
| |
| | |
Bug: 14425059
Change-Id: I3eb24e840c165e43f68c2a60fccf9974affb57a6
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Bug: 14425059
Change-Id: Ieace636334a9b2a094527341d4fcfc05958296c5
|
|/
|
|
|
| |
Bug: 15412461
Change-Id: Ibf37df4d31141a7e43b54d6342e7861eedb1c03b
|
|
|
|
|
| |
Bug: 14425059
Change-Id: I2bd6a872904a44b80f638a13d91a97559217cc1a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The symptom : when text is selected and the device is rotated,
sometimes the keyboard sets the word as being composed around
the start of the selection. Upon the next rotation this ends up
with the keyboard committing some text in place of the selection.
The cause : another bug in the framework with rotation >.>
The keyboard receives a call to startInput with a wrong cursor
position, namely one that does not represent a selection. The
keyboard sets a composition according to this wrong data. When
the keyboard is rotated again, it commits the text, which takes
the place of the selection.
The solution : actually when restarting input the keyboard
realizes that the cursor position is wrong. We cancel composition
at that time.
For robustness, this change also implements two other defensive
changes : upon call to onUpdateSelection, we actually realize
that the previous values were wrong, so we also fix it at that
time, and in addition, when rotating, we finishComposingText()
instead of commitText() which is less dangerous. Implementing
this later change also allows us to let less internal variables
from InputLogic escape to LatinIME, so it's also a good change
for design.
Bug: 14140799
Change-Id: Ib10de18e53e376ac1bbc8487e13d969828483346
|
|
|
|
|
|
|
|
|
|
| |
This fixes PunctuationTests#
testAutoCorrectionWithSingleQuotesAround.
Bug: 14119293
Bug: 15334309
Change-Id: I604c21a21e89a5fc431fd56ab7b6ad03f4736b01
|
|
|
|
|
|
|
| |
This CL must be checked in together with I5cc76807e3.
Bug: 15318007
Change-Id: I61423c3377ddc299fb332e742d6626c2e47145bb
|
|
|
|
|
| |
Bug: 14119293
Change-Id: I5020e5f0aa64bc3e97b3a3c2c07a60c8b765ed64
|
|
|
|
|
|
| |
Bug: 14119293
Bug: 14425059
Change-Id: I65320920e840082b0b697bb621676716d0933e0c
|
|
|
|
|
| |
Bug: 13312942
Change-Id: I6be6a558bbc6c88508150f9c25cadbd0240ff88e
|
|
|
|
|
|
|
| |
Nice recipe for failure
Bug: 13387534
Change-Id: Ida1978449c1997587b2ec0955c5c94fcef336121
|
|
|
|
|
| |
Bug: 13136079
Change-Id: Ieae6bafbd5339a033f0f342ba9af7dcc4ce209fa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The heuristic in RichInputConnection makes little sense
when textLength > mExpectedSelStart but we have
more than 1024 characters of text. If there are that many,
it's about 100% sure that 1024 is not the correct cursor
position. With no good guess, we'll just continue trusting
the app, even though we know it's lying : at least it will
make the problem visible to the app author.
Also, there have been a lot of confusion about initialSelStart
and initialSelEnd. The keyboard should log them so that
it helps us and editor authors debug more easily these
common problems.
Issue #65170 in AOSP and
Bug: 12772035
Change-Id: I6665a16c9f2832d33ee323f033bb38bcc092a3b4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the cursor is moved by the user, the RichInputConnection
is told about it. However, to work around a framework bug, it
also looks at how many characters are in the buffer before the
cursor, and if that's more than the value it's been passed, it
deduces that's a framework bug and there are at least as many
characters as seen before the cursor, so it puts the expected
cursor position there.
When you move the cursor, TextView calls onUpdateSelection,
and when you move it fast, you'll get rapid-fire calls to
onUpdateSelection. This is fine, the RIC is equipped to
deal with that.
However, these calls take some time to make it to the IME. In
this instance, when the first call gets through and the IME
calls TextView (synchronously) for text before the cursor, the
cursor has already moved in the app, and TextView returns more
characters than the cursor position was declared to be in this
instance, so the RIC sets that as the expected cursor position.
Sure enough, a split second later, the second call to
onUpdateSelection arrives, with the new cursor position set
where the RIC had found it too early. The RIC takes that as an
"expected" cursor move, and the input does not get reset.
Luckily, we have a way out. As far as we know, the framework bug
only manifests itself upon rotation, which means we should only
have to adjust for it in onStartInputView. Doing it in
onUpdateSelection is too zealous (and probably too distrustful of
the app to send the correct cursor positions).
So we should just take care of the rotation case (by calling
tryFixLyingCursorPosition in onStartInputView) and remove the
compensating code in resetCachesUponCursorMoves.
Bug: 12982502
Change-Id: Ic3c1408a1ec45deaea63b01d98376a79ae567d77
|
|
|
|
|
|
| |
Typo fixes and clarifications
Change-Id: I0f7e0b6e665232bb995172fff10521c7f17599eb
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During recorrection, the cursor position when calling
commitText is not necessarily at the end of the
composing text.
Besides, RichInputConnection assumes the cursor is
always after any composing text. This is not correct,
but in the practice, it seems all code paths work.
We should fix this in the future.
Bug: 13060691
Change-Id: I15f71fff62d36e80cf6e4a022c5e78af634b199d
|
|
|
|
|
| |
Bug: 11447084
Change-Id: I5bd558b9dd85d1505aa918f44e8ac3e52ec42d97
|
|
|
|
|
| |
Bug: 8911672
Change-Id: I5d5635949530a67f95e5208986907251b7bce903
|