terminate method is no longer needed since handles are popupWindow
which have their own fade-out animations.
Change-Id: I8354f78ece2ffe9c098ef2f02f0d637fc4c813c0
bug:3452868
1. Now hiding the input controls, which also cancels the input controls
fade-in animation, on every intercept of down since the fade-in
anumation flips a flag used to guide the drawing of the input controls.
Note that we also want the scroll wheel shown on down but the fade-in
anumation is actually hiding it upon completion.
Change-Id: Ib161ed757e537365b21e6913370d264152dca1fe
Bug 3329346
Making sure the cursor is never hidden by the finger. Some
vertical movement is not repercuted on the handles' position
if it moves the finger closer to its 'ideal' touch position,
where both the insertion line and the top of the handle are
visible.
Also removed the hysteresis line filter which is not that
usefull and feels sluggy.
Change-Id: I6ad0fed0cf66753c6571b3bc620b1a0f2397c7b2
Bug 3416154
The origin of the problem is new display optimisations that enable
a scrollView to be scrolled without calling the onDraw method of its
children. As a result, the handles' positions were not updated on scroll.
DropDown popup menu have an integrated scroll listener that will fix the
problem. Using these indead is the first part of the solution.
The next problem is that when they get hidden, these popups try to move their
parent (the TextView in our case) which creates a scroll conflict. Fixed by
overriding findDropDownPosition.
Finally, when the handles get invisible, a new scroll listener has to be
installed that will show them back in case the view is scrolled back.
This is also an important step to fix Bug 3441308 (selectable text in list
views).
Debugging find outs:
Small optimization in PopupWindow to avoir unregistering then registering
back the listener when it is updated.
getHandle().show(); is not needed since updatePosition will do it through
moveTo().
Change-Id: I6bf6a3649538328257734ed1e651b23b889d65d9
Bug 3436027
A movement has to happen recently, and there has to have been a stable
period before this.
Also fixes a problem with the paste popup that could be displayed for very
fast motion since it was only based on time and not on distance.
Change-Id: I02264b4d54e4d1323ebc2d1b5102769ba2d8569a
Bug 3394800
A previous fix called cancel when the window was detached. The cancel/uncancel
mechanism does not actually removes the Blink runnable.
It is indeed more a suspend, which is used when the window loses focus.
The problem here was that uncancel was never called.
Removing the runnable callback instead.
Also rationalized the use of makeBlink and the setting of mShowCursor
Change-Id: I92aac43a891991b7cc98738de0f12332ab16907a
Fix for issue #12945: Changing the maximum of a progress bar does
not cause it to be redrawn, even though a new maximum changes the
position of the current progress in relation to its maximum. With this fix,
setMax() will always cause refreshProgress() to be called if the maximum is
different than it was before.
Change-Id: I971ec3302953bcadc0aac3dd8241481bab2b5a91
Be more conservative with when we let an AutoCompleteTextView's
dropdown box of completion suggestions cover the IME.
Disable the expand-when-touched behavior of the dropdown list when
more than 3 items can be seen at a time without it.
Don't let a ListPopupWindow that is expanding in response to touch
scroll the anchor view within its parent and slide the dropdown out
from under the user's finger.
Change-Id: I009accfd4e841c9a5e1072735d8a0b067a0bc06a
Bug: 3225887
Bug: 3453253 (possibly)
Since some apps call setIconifiedByDefault(false) at the initialization step,
it isn't a good idea to open/close the keyboard during this call. Apps
can call setIconified(false) instead to invoke the keyboard.
Change-Id: I9d5d08b74055a3e99053d647df0cd4c7953bae80
Clean up handling of a few conditions in MenuPopupHelper that the
monkeys manage to trigger around the use of ViewTreeObserver. (bug
3443819, bug 3312949)
Fix a bug where a stale handler message could cause a ListPopupWindow
to reopen itself after being dismissed. (bug 3453607)
Change-Id: I488014767ccee785500862a2572beb35901d173b
Bug 3261766
If defined, the drawable is used instead of directly drawing a 1 pixel
line. This makes the cursor more fancy and more visible.
The drawable is currently clipped by the TextView's limits, which is
currently visible on the left when the cursor is at the first position.
To solve this issue properly, we would need to propagate a do-not-clip
up in the hierarchy.
Change-Id: I99f6001048eed14104994acf6bab942dda8eb38e
Bug #3431451
This bug was causing ListView to not render properly when showing an item
larger than the maximum drawing cache size. ListView relies on the drawing
cache to correctly mask all the background pixels. However, if the cache
is not properly created, the background will show through even though
ListView.isOpaque() == true. This change detects this case and falls
back to the default non opaque behavior.
Change-Id: I30a45e7a03fb7ebb2b12f0e85c075c2901954c44
Bug 3415891
With the current behavior, as soon as the list is expanded by
'long' pressing on or scrolling its content, it will always further appear
in its long state, thus hiding the IME.
This fix changes this behavior so that the default state is always
compact, not hiding the IME, and an explicit expansion
is always required.
Also fixes a bug in ListPopupWindow that prevented the timer that
expands the list from being started.
Change-Id: I896e92d54961769c10b276c36f6510e91ff096a2
Bug 3330651.
The first item in the list is not selected by default. From discussions
in other related bugs, there does not seem to be an agreement on this.
Supporting the actual token separator has also been punted. This would
require a new method in the Tokenizer, which could be ill-defined for
exotic tokenizer, plus typing a comma (for instance) to achieve a
completion is not a common pattern.
Change-Id: I30baf62077c412256175f871d21f4841e104f212
