Before the suggestion selection were notified only when they were added by
an IME. This CL relaxes this constrain, and the suggestion are notified
even if they are added by an application.
If the context is null and the package name of the apk cannot be determined,
the suggestion are notified using the old method via the Input Method Manager.
This is required to keep the backward compatibility.
Bug: 6905960
Change-Id: If225ef27cded386809fbd899e34e32aced4e0473
All variations of getRelativeTimeSpanString() now properly handle dates
that are in the future. Prior, the version used by
getRelativeDateTimeString() would occasionally show the time instead of
a date when the future date was the same weekday as the current weekday.
This resulted in the time output being duplicated, eg.: "11:23, 11:23"
Change-Id: If20972a6942cce792fa233437f94dedfb71379f3
Signed-off-by: Steve Pomeroy <steve@staticfree.info>
We were doing line breaks after punctuation as long as they weren't
surrounded by digits. This is a misinterpretation of the Unicode line
breaking algorithm. Punctuation (class IS) is not hugely different than
the default classes (NU and AL) - there are breaks after punctuation
that are allowed (for example, followed by an open parenthesis), but
we're not implementing the algorithm with anything near that level of
fidelity.
The long term fix is to really implement the algorithm. In the shorter
term, the easiest thing to do is to remove the special case altogether.
Change-Id: Ic4dc3216c2a4191fbb7cfa06e9dc038d1a56398c
Cherry-pick of I7f1b0d49a2ece957a7b9b5d65d48385bf2c2a668 from master.
I've also provided TextView.setTextLocale() for use in single-language
TextViews.
Change-Id: I5692859bfd2aafc284172454d943afc250b22535
This brings DateUtils and Time in sync with bionic, icu, WebKit,
DateFormatSymbols, Formatter, and SimpleDateFormat. And specifically
means that DateUtils now knows how to say "AM" and "PM" in Japanese.
Bug: 6719054
Change-Id: Icdd75c0865505fde4115d71025eeb7515b73da4c
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I64ef06df0eb06f75aedd25de97e9f347eeb52979
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I12c7a2311a9bdbbea7ab21554a922b7f665a17bf
Skipping spaces at ends of line used to be done only when ok != here
(a potential line break was found).
Moved this logic up one level to handle all cases.
Also moved maxLine test in the block that actually adds a new line.
Updated the unit tests accordingly.
Change-Id: Ib10bc838b1ffa5b8a60259ea4b622d9fecb2ec70
Bug 6598784
The algorithm uses three imbricated loops:
- paragraphs
- span regions (called "blocks" in that description) in these
- characters in these
We can ignore the paragraphs and assume paraStart==0.
The span region loop cuts the text into blocks of text which share
the same set of MetricAffectingSpan spans applied to them. Note that
spanStart and spanEnd represent such a range, and not necessarily an
actual span range.
The third loop then iterates over the characters of these blocks, and creates
a new line (calling out() as soon as the width has been reached.
The core of the problem comes from the 'nextSpanStart' variable.
It is used to restart the block loop from a previous position in case
a line has been created that does not intersect with the current block.
However, in case the current block is larger than the width of the text,
the character loop is going to create other lines of text before we exit the
j-loop. Going back to the block loop, we reset spanStart to the nextSpanStart,
which may be too far back in the text. As a result, the same range of characters
is measured again.
The (spanStart == spanEnd) test was used to handle the case where
nextSpanStart was indeed assigned to a value different than spanEnd.
This fix simplifies this logic and removes the nextSpanStart variable:
When the created line ends before the current block (here < spanStart), we
immediately exit the character loop, re-starting the block loop from the
current position.
Patch 4: added a fix in measured to handle overlapping character ranges.
Change-Id: Ie71b3cf4018b332e335ea916fef08acb43a6679e
Bug 6642222
Using setMaxLines(0) and setMinHeight(30) causes a crash
because Layout#getLineRangeForDraw() returns a [0,0] interval
in that case.
Accessing the Direction in draw causes a NPE.
Change-Id: If50f9b554e3cdc598a721b623992e9196982838c
This change is analogous to Ic0e9f1bbd8cae9fdd3a6d1d015bb9224c8be545c
in WebView, and depends upon the same Skia change that that CL makes
use of.
This flips the "fake bold" flag on for bold fonts in
TextView.setTypeface(), with the expectation that Skia will ignore
the flag if the final typeface used to render the glyphs is already
bold. It also does the same for StyleSpans, TextAppearanceSpans,
TypefaceSpans, and the Switch widget.
With this, fake bold should work uniformly across all scripts - if
fake bold works for a primary typeface, it should also work for all
fallback typefaces.
Bug: 6629786
Change-Id: Id3b8639ab0df83052ffd82809cb12adaacc1d46b
Make clearer how the platform is handling key events following some
unfortunate uses by third party applications. Also highlight the
changes in Jelly Bean default keyboard.
Bug: 6566711
Change-Id: Ibcdaf54c6d629fd0733529bfe2fffc82f555f084
Bug 5763685
To improve performance, preventively cut the the into display
list of 3-10 lines of text. Further updates to small parts of
the text (such as adding an underline on a word) will only
invalidate and redraw the affected sub display list.
DLs are aligned with paragraphs, just like they will be during
text edition.
Change-Id: I0d60debc7fdaea8b29080a6eacb2d60205e7d547
Bug 6448052
The empty EXCLUSIVE removal condition was incorrect.
Also changed the unit test the didn't catch this problem.
Change-Id: I5576d830cdfa6cc3716c878fb698695a2978b296
Bug 6343982
Finally deeply understood the meaning of the POINT and MARK flags.
Updated the Spanned documentation to reflect this.
Updated tests to come.
Change-Id: I400d56b7b4929bc1e7eb4f0497d8e081ee23682e
