Bug 3228601
A tap on the insertion handle displays the paste popup immediately.
Tapping again hides the popup.
Bug 3248651
Change-Id: I5a501b3ebe36e23cbbf0f1b3d588884c6ecd1d56
Bug: 3140925
Removed all the code from SearchDialog that is already in SearchView
and moved more stuff into SearchView.
SearchDialog layout changed to be more like a Holo.Light themed action mode.
Search field is right justified and limited to 500dip.
Zero query dropdown added to SearchView (causing some problems with Gmail,
but that may be an existing issue that's only now showing up due to this change)
Holo.Light search views assets still need to be updated, as the contrast is too low.
This extends the view hierarchy's measure pass to allow view to
propagate up to their parent additional information besides just
their measured size. They can now report that their measured width
and/or height should be larger than the size their parent is
limiting them to (even though by definition they need to contrain
their reported measurements to the limits imposed by the parent).
ViewRoot uses this information to determine if it should remeasure
the window with a larger size limit to try to make it fit.
Change-Id: I90af3b7a8ec45d0a5c003fb009857025209d83eb
Refactored to use a custom Callback instance instead.
This instance can be shared by different TextView, which no longer have to
be overloaded.
Change-Id: I4749905d8e2057dab2b3ded62bd7c388d13d4e57
Add divider attributes to LinearLayout, plus styles for borderless
buttons. Update text field assets.
Change-Id: I673acab1692cc028a0327e8c154069253a4d52e8
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
Restored the interpolator and a constructor with 4 parameters.
New spline coefficients, spline computation moved to MagneticOverScroller, which has been
renamed SplineOverScroller.
Change-Id: If1ab2653bb998600e9c5d6f46dfd6cd30fa44efc
This fade out was mainly introduced for forms with selectAllOnFocus fields, where
is hide some content. These no longer trigger selection mode and hence do not display
the handles.
Handles will be visible as long as selection mode goes on.
Change-Id: Ib8c2cc97308a91722f69aa0bb0caccb21d94c2c4
New algo is:
1) if view width < MIN_WIDTH (currently 300px), clip glow and edge to fit
2) else stretch glow and edge to fill width
3) make alpha and height of edge and glow 30% "more intense"
Change-Id: I8f121bb165a8fb835bc33950dbedd1bc80c5df65
Between the animation system, ListView, and this, we can now account
for the large majority of animations in-flight at any point and annotate
StrictMode violations accordingly.
Note that StrictMode.Span goes out of its way to not allocate memory
and is very light-weight, especially on user builds where it's a
no-op.
I've tested this with the LOG_V debugging in StrictMode and I think
I've gotten all the entry/exit cases of ScrollView's animations. At
least, I'm not able to get it out-of-sync at least, even with
orientation changes during scroll/fling, etc. It's possible I missed
a path, but that should show up as excessive false positives during
dropbox uploads if so.
Change-Id: I3b0545111a775d9fa8e171f2a190031f1b56c4c0
Bug:3085564
In order to treat the selection handles properly, the text in
WebTextView needs to line up with the text in webkit. Use the
line spacing style, or the paint if none provided, to determine
the spacing for WebTextView's Layout. When no line spacing is
provided, use the floating point values of ascent and descent,
rather than the rounded result, to determine spacing.
Requires a change in external/webkit:
https://android-git.corp.google.com/g/#change,80641
Change-Id: I51081835e128a0e938028c7c7aeb5111aa5f072c
When transitioning from a fling to a touch the mode was being set
to idle instead of ending up in scroll. This corrects the
notifications to get sent in the correct order.
Change-Id: Ideed6e4064b2be62788307f4232015fa88e101b4
Noticed after logs showed a ton of false positives, I went back and
looked at the history. During the review of the previous CL, I
accidentally moved the finish() of the fling animation tracking inside
the PROFILE_FLINGING block, which is normally off.
Re-tested this CL with StrictMode debugging enabled and it now always
propertly resets to 0 animations in flight when no animations are
running.
Change-Id: Ie9746df36e2ec3f82679b20e91e3d93c05b863d4
BREAKING CHANGE: Redesigned the key character map format to
accomodate full keyboards with more comprehensive suite of modifiers.
Old key character maps will not work anymore and must be updated.
The new format is plain text only and it not compiled to a binary
file (so the "kcm" tool will be removed in a subsequent check-in).
Added FULL keyboard type to support full PC-style keyboards.
Added SPECIAL_FUNCTION keyboard type to support special function
keypads that do not have any printable keys suitable for typing
and only have keys like HOME and POWER
Added a special VIRTUAL_KEYBOARD device id convention that maps
to a virtual keyboard with a fixed known layout. This is designed
to work around issues injecting input events on devices whose
built-in keyboard does not have a useful key character map (ie.
when the built-in keyboard is a special function keyboard only.)
Modified several places where events were being synthesized
to use the virtual keyboard.
Removed support for the "qwerty" default layout.
The new default layout is "Generic". For the most part "qwerty"
was being used as a backstop in case the built-in keyboard did
not have a key character map (probably because it was a special
function keypad) and the framework needed to be able to inject
key events anyways. The latter issue is resolved by using the
special VIRTUAL_KEYBOARD device instead of BUILT_IN_KEYBOARD.
Added the concept of a key modifier behavior so that
MetaKeyKeyListener can distinguish between keyboards that use
chorded vs. toggled modifiers.
Wrote more robust key layout and key character map parsers
to enable support for new keyboard features and user installable
key maps.
Fixed a bug in InputReader generating key ups when keys
are released out of sequence.
Updated tons of documentation.
Currently QwertyKeyListener is being used for full keyboards
with autotext and capitalization disabled. This mostly works
but causes some problems with character pickers, etc.
These issues will be resolved in subsequent changes.
Change-Id: Ica48f6097a551141c215bc0d2c6f7b3fb634d354
