Removing "settings" key popup from these keys when there's a dedicated
"settings" key in the layout.
This is followup chnage of I119528c0.
Bug: 4196879
Change-Id: I742cc6d1d890c095610f1e8b9ac91a044ec540b7
Because handling shift locked state of alphabet keyboard is done by
KeyboardSwitcher, there is no need to change the "on" state of Key
when releasing the key. On the other hand, symbol and symbol shifted
keyboard has fixed "on" state "ALT/MORE" key.
This change also renames the attribute "isModifier" to "isFunctional".
Change-Id: I082885bd2376ae26bdfc378c14add2b5d6be1d4e
When user starts sliding key input, sliding through successive
modifier key will be ignored.
Bug: 4181843
Depends: I082885bd2376ae26bdfc378c14add2b5d6be1d4e
Change-Id: Ibe890b9cc1183dbe9f68a421650fcd97e7ff221c
- VoiceConnector to VoiceProxy
- VoiceInputConnector to VoiceInputWrapper
- VoiceLoggerConnector to VoiceLoggerWrapper
Change-Id: I908ddc590c8846cf5cbd80b9c0257cb65c638bde
Ic4df2a9a introduced new keyboard layouts for Hebrew and Arabic.
This change adds a comment to them alongside with trailing
whitespace suppression.
This change explicitly limits its scope to files introduced by
Ic4df2a9a. It replaces I48927626 which has been deemed too reckless.
Change-Id: Id6b0e47f0623ead0b4e42e57dae359231a2b97fc
The Arabic keyboard is more or less based on PC keyboard and other
sources. It has no means to input diacritics at the moment.
Some data for the Hebrew keyboard was already there, but not used.
This change splits phone and tablet layout and consolidates the
tablet one to something that seems sensible. It can't input diacritics
either at the moment.
Other shortcomings affect those keyboards. For example, normal
Hebrew keyboards switch to capital QWERTY keyboard with shift on,
as there are no capital Hebrew characters, but this version does not
feature this.
It should be mostly possible already to enter Arabic or Hebrew with
these keyboards however.
Change-Id: Ic4df2a9a77ffd03c4f9ee2c47e03c0f43f8e48ae
Background:
Both SubtypeSwitcher and VoiceConnector have an instance of VoiceInput.
And VoiceConnector has a responsivity for setting VoiceInput to SubtypeSwitcher.
But in case that VoiceInputConnector already has an instance of VoiceInput
VoiceInputConnector doesn't set VoiceInput to SubtypeSwitcher.
Change-Id: I42d0220e7d84a08e03f143213cc6eff87e7e79a6
This change adds basic support for an external dictionary provider.
It adds methods for reading the dictionary itself from an asset in
the dictionary provider package directly, obtaining the file name
through the ContentProvider interface; it also adds a way of getting
the data through an InputStream and copying the file locally.
Incidentally this change also adds the code needed to listen for
updating the dictionary provider package and reloading it in time.
This change also goes hand-in-hand with Iab31db6e, which implements
the small closed part of this.
Issue: 3414944
Change-Id: I5e4fff99a59bb99dbdb002102db6c90e6cb41c8a
This changes:
* Flag initialization code in BinaryDictionary to be more unit test friendly.
* Removing unnecessary class hierarchy of LatinIME inner class WordAlternatives.
* Formatting normalized score neatly.
Change-Id: I9f10c093d4f36258fe883cf3fb10cbbda2770497
This change also corrects usage of "frequency", "priority" and "score"
* Frequency is the relative probability in dictionary.
* Score is the relative probability in suggestions.
* Priority is kind a sorted score.
Change-Id: Iafb135a4ecdb401cc505014a07c74dfcac44d699
It used to be the case that the scoring system turns up the same word
that was entered with a different capitalization, but with a lower
score than some other, more frequent word. To cope with this, there
was code that would order such candidates in the first slot no matter
what. This processing is now useless because fully matching words now
have a huge boost that ensures they will get to the top of the list,
before any non-fully matching word (which means, differing only by
capitalization or accents).
The bug that did happen with this was, if a fully-matching word got
matched by several processing passes, and the (chronologically) later
score affected to this word was weaker, it would result in the
duplicate removal pass removing the stronger score. This in turn would
mess with autocorrect.
In an effort to keep the risk at a minimum for MR1, this change does
not actually remove the useless code, but adds a check in the odd case
to avoid the bad situation. Another change will remove the code for
ICS release.
bug: 4100269
Change-Id: I18c0575332981ffec0e257e26a360995838d521e
