The logic was in TextView, but it's only for Editor.
Move it to Editor and have constants for the state.
Bug: 19544351
Change-Id: I391f66753aa5cbb26fbefcba5b4e7e3d917454e2
- Detect triple click in TextView#onTouchEvent.
- Select paragraph on triple click.
- Extend drag accelerator to support paragraph based
selection.
Bug: 19544351
Change-Id: I0a6752a0642a2c569b69a1fc2c0f49169a72844a
Now, the handles will be shown at the proper positions in
Editor#startSelectionActionMode. No need to call
HandleView#showAtLocation.
Change-Id: I5a7fb7bc4419a49234584bd06db5acc3d23168b8
- Remove mouse selection related logic from
ArrowKeyMovementMethod and Touch.
- Extend drag accelerator to support character based
selection by dragging and use it for mouse drag selection.
- Enable word based drag accelerator even if the clicked
position is not on a word.
- Disable y-coordinate adjustment for word based drag
accelerator when the user is using a mouse.
Bug: 19544351
Change-Id: I1b29a65be3d321ac472f8c5b70ab6fee4e895964
This reverts commit c55d5072ac.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
Previously it would snap to the floor(progress) tick, which makes the
touch target size for the last tick 0px wide and difficult to touch.
Change-Id: Iac488d73e5a67c29b45f9bb4368db46c0028483e
A bug in recent layout optimizations was causing the framework to avoid
laying out containers with WRAP_CONTENT in one axis or the other.
This fix updates the logic in the code that finds dependent layout axes
to correctly account for this case.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ie5f678beef5d8c4ba25291ffdcd59797d4697acc
The reason that manifests is because SV's
onInterceptTouchEvent checks if it's scroller.isFinished()
returns true. The result of Scroller.isFinished() is only
valid if it has had computeScrollOffset() called on it before.
ScrollView currently posts a invalidation after a computeScroll()
call, which means that isFinished() *should* be valid, but it's
better to be explicit which CL adds.
BUG: 26051101
Change-Id: If78f48dc855de1776011cb7b0f95cb0a80d9b777
This is the 2nd try of I39dc0c310158ad23ba6c987efce07deaf30ce693.
This is a mechanical refactoring with no behavior change.
With this CL, InputMethodSubtype and SpellCheckerSubtype have the same
getLocaleObject() hidden API, which makes it easy to share the logic in
subsequent CLs.
No behavior change is intended.
Bug: 11736916
Bug: 20696126
Bug: 22858221
Change-Id: I51be014c752b736a808e2b0d56e664941a218a2f
This is a mechanical refactoring with no behavior change.
With this CL, InputMethodSubtype and SpellCheckerSubtype have the same
getLocaleObject() hidden API, which makes it easy to share the logic in
subsequent CLs.
Bug: 11736916
Bug: 20696126
Bug: 22858221
Change-Id: I39dc0c310158ad23ba6c987efce07deaf30ce693
The primary goal of this CL is to enable application developers to
provide more context-based language (locale) information for IME
developers so that users can be benefited by more natural text input
experience.
As of API Level 23, there are several APIs that allow IMEs to retrieve
locale/country related information.
- Locale#getDefault()
- Configuration#locale
- LocaleSpan#getLocale()
- SubscriptionInfo#getCountryIso()
However, only LocaleSpan#getLocale() can be used to pass application
specific languge (locale) context from applications to IMEs. Also
LocaleSpan is not designed to be used per input-context. We want to
have something in EditorInfo and LocaleList would be the right thing.
Although default implementation of TextView#onCreateInputConnection()
starts filling EditorInfo#localeList with TextView#getTextLocales() by
this CL, application developers are encouraged to provide its own
LocaleList when they are confident that the user want to use a
certain (set) of language(s).
For instance, a chat application may be able to guess what language will
be used in the conversation before the user start typing. At least it
should be able to remember the last used language for each conversation.
Another instance would be "From" and "To" EditText fields in a
translation app. Those fields should have different LocaleList based on
the languages that the user want to translate from and to.
Bug: 22859862
Change-Id: I77db5b99a7cf745d800db75baf135bb60ad04820
The logic to detect vertical expansion is inverted on RTL
text. As a result, the selection handle cannot be moved
when it's dragged toward vertically expanding and
horizontally shrinking direction.
Bug: 25893288
Change-Id: I096595d287261b1287862c6ad27ae7f6f0a73262
* changes:
FalsingManager Quick settings fix
Fixed a bug where the panel could be too small in certain cases
Fixed a bug where the margins where not updated correctly
Fixed the handling of the expand on the lockscreen
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
Remove code duplication in SelectionStartHandleView and
SelectionEndHandleView by introducing SelectionHandleView.
Change-Id: I4486019714b13d184a72cf7ee60c346c4d8b5f5a
When updating a notification, the end margin was not
correctly updating, leading to overlapping text with
the image.
Change-Id: Ica3d21ff0268105d0a8a73527b8dad0225e12d5a
If there is an image instead of applying the same
margin everywhere, the text now floats around the
image.
Change-Id: I87f9ca9f51fb270b0732a99374544381bd1fc4e0
Most of the notification templates have been updated.
Some cases like media notifications don't yet work well
but will be fixed in a later CL.
Bug: 25376106
Change-Id: I26c366e58ebba3852cea20de6fca311bd302bb24
Previously we would check whether relayout was required and optionally
invalidate; however, with partial layout we leave this work for the
makeNewLayout() method. We still need to manually invalidate, though,
since makeNewLayout() does not handle invalidation.
Bug: 25857300
Change-Id: I81ef9062c9fb4964d5e42a3562e6c782492ad65f
This is a mechanical replacement of Context.getSystemService(String)
with Context.getSystemService(Class<T>) when retrieving
InputMethodManager. Note those are bundled code. Hence we don't need
to make sure Build.VERSION.SDK_INT >= 23.
Change-Id: Icc64942ad8f11e44bf84f8d4fe476b2fdd1257f3
Refactors the menu helper classes. Both classes now implement a common
MenuHelper interface, which eliminates the need to keep separate helpers
on PhoneWindow and unifies the DecorView showContextMenuForChild()
implementations.
We now explicitly dismiss any previously shown context menu before showing
a new context menu. Previously we relied on the modal nature of the dialog
context menu to prevent multiple menus from being opened at once, but this
is no longer reliable with popup context menus.
Bug: 25656520
Change-Id: Idab3daa6d6888f803f2e33660fe1dd488e4c28d1
- Set an id for each HandleView to access the hanlde.
- Rename DragOnTextViewActions to DragAction to use it for
dragging handles.
- Introduce HandleCoordinates to provide proper coordinates
for handles.
More tests will be added in following CLs.
Bug: 25730231
Change-Id: I9276bf2f983983ec9aae0ddcf674d3dcee566892
To make suggestion window style Material, this CL does following things:
1. Introduce LinearLayout to be able to split suggestion item and menu.
Currently suggestion menus, "Add to Dictionary" and "Delete" buttons
are children of ListView. It is necessary to introduce LinearLayout
and move these two menus from ListView to this LinearLayout to have a
divider between suggestion items and menus.
2. Extract suggestion window layout definition from Java.
Currently almost all layout of suggestion popup window is done by
Editor.java. By extracting this logic from Java and move it to XML
files, it becomes easy to support both Holo and Material theme.
3. Introduce Material Design.
Suggestion window should respect the running application's theme since
suggestion window is shown as the part of the application.
This patch introduces Material themed suggestion window, and at the
same time, the old window is also kept as the Holo themed suggestion
window.
Bug: 15347319
Change-Id: Ieccea12db95c0a040b38680ae794b1cf6971736f
Previously the dismiss callback was called immediately after the menu
received a close request; however, the dismiss callback implies that
the menu's window has finished animating and been removed from the
window manager.
Also cleans up handling of mPopup in MenuPopupHelper to prevent
unnecessary MenuPopup allocations and convert unnecessary fields into
method arguments.
Bug: 25323707
Change-Id: I8e3877ae6c40b4d0f1df23a4ff4fa48a7df34e0d
NearestTouchDelegate may still be assigned to non-ViewGroup views, but
we won't attempt to find a target child View until the touch moves into
a ViewGroup.
Bug: 25813455
Change-Id: I570f88fee63623110e3463e8d4579cca8113fd5e
A previous CL removed setLocale(), which had been initializing the temp
calendar. This CL also makes the calendar final, since the locale is only
set once during construction.
Bug: 25776094
Change-Id: If0af34df3120a7c4b1667129a553b9f8b7ec1999
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
Previously, TextView setText and append methods set the movement
method to LinkMovementMethod only when autoLink was enabled and
Linkify was able to find links in the input text. This CL adds the
case where autoLink is false, linksClickable is true, and the input
text contains ClickableSpans.
Fixes https://code.google.com/p/android/issues/detail?id=2219
Bug: 1712837
Change-Id: Ife4e35bac7f6cb48ad0dac6ecb4b90aec126fc73
We want to limit the number of size thresholds that an application will
report. Instead of using a dimen resource that will increase the number
of thresholds, we calculate the max number of action buttons dynamically
in code.
Bug: 25394588
Change-Id: I8ece331cd02fb116b49734003cec112708d27f85
