There are 3 classes coordinating the gesture: PinchToOverviewListener,
PinchThresholdManager, and PinchAnimationManager.
- PTOL listens for the pinch gesture on DragLayer.
- When a pinch is detected, the PTOL keeps track of the interpolated
progress and passes it along to both the PTM and PAM.
- The PTM uses the progress to determine whether a new threshold has
been passed, and tells the PAM to animate it if so.
- The PAM uses the progress to animate things like workspace scale
throughout the pinch.
- If the pinch ends early, the PTOL uses the last passed threshold to
determine whether to animate to workspace or overview, and tells
PAM to perform the animation at the same velocity as the pinch.
Bug: 24414635
Change-Id: I9e53706c705f8b2982409bf7c223d8d0e9618bf0
> Sending unboundX to the overlay which is the total untranslated X and not just deltaX from last frame
> Handling overlay callback and translating workspace accordingly
Change-Id: I3bd8d9efac738e9ce131758f0e5ff1b9c1d6a8fc
-> Created com.android.launcher3.folder package to house most folder-related files
(aside from the FolderInfo) which is more related to the model than the UI.
Change-Id: I767063e1e4c775c01a799a3bede30cd94ac48ade
dispatchDraw was calling getVisiblePages which in turn calls
getDescendantCoordRelativeToParent and created multiple new abjects
Change-Id: I401fec076183979d30dfdbbdc02a57bd79f3886d
Clearing the focus was causing the first child in the new page to
immediately take focus, which caused FocusIndicatorView jank when
using a keyboard.
Bug: 25256728
Change-Id: I5ab31ebc3fe370d7ac9e9792b30dab3467023738
The navigation bar is opaque on mobile devices in landscape mode.
Launcher should ignore the right insets and draw the edge effect appropriately.
Also draw the black bar under the navigation bar, just in case we assume it
to be opaque, but it was not actually opaque.
Bug: 18526657
Change-Id: I1d49dcb82b8a5ee25009bc738cd9b8c0c5c88263
The search for this page starts at the current one and
continues to the right (on LTR) until a page is found that
can accomodate the widget, taking possible resizing and
reordering into account.
Bug: 11338870
Change-Id: I2e9a310eb8f74024dca9150f55a525e1309c2f07
Previously there was a workaround to ensure that adjacent panels were visible
while in the overview or spring-loaded states, but it incorrectly kept only
those original pages visible even while the user scrolled to other pages. So now
we only use the workaround when first entering the overview or spring-loaded
states, and then fall back to the default getVisiblePages() implementation in
PageView when in free scoll mode.
Bug: 23766408
Change-Id: I692ec00b9cd6d7889c374aee41b85abd0a5d8d3c
This is per an earlier CR comment "we should probably move all this code to its own package (launcher3.dragndrop) in a separate cl".
I'm not moving DragSource because it's referred from gsa code.
Bug: 22609426
Change-Id: Ia7204dab99c0c395c66b77143a2d60411153f5f3
> Renaming Lmp to Lollipop
> Lollipop_MR1 instead of directly using 22
> Using M APIs directly instead of reflection
Change-Id: I10a307f46e3be15b3299f549a2fd7e0e215a6a1b
> Instead of resizing the rect for dragoutline in onDrow, store the resized rect itself
> Remove unnecessary inverse matrix calculation
Change-Id: If13c3c5aaecba5a1d3a4f5d39199ed82e9662c62
> Using View property instead of strings to avoid extra reflection step
> Using ViewPropertyAnimator when several properties are being animated
Change-Id: I41625643b38b70bac11e2c81d18058ec878d73bd
> Using the currect right page index in rtl
> Updating current scroll after max scroll has been calculated. This prevens an extra overscroll when the layout happens for the first time.
Bug: 22358804
Change-Id: If07132701936e06f727211122a3b3e6f8426c07b
-> When in overview mode, flinging the pages can leave the scroller
running (invisibly) for much additional time, since the scroller
fling bounds far exceed the alloawble scroll bounds (in order to
achieve a hard wall type effect)
-> When this is happening, user couldn't pick up a page for reordering
-> Ended the scroller early in this case to avoid the problem
Change-Id: I8b6f140d9a87bb742e57625e90ca7d76a2158e28
> Make package-private and @Thunk all private methods and constructors accessed from inner classes.
Change-Id: Ie5913860a0c33e48e9bf68f9b5b1699f64c2f174
The reason for non-scrolling was excluding the pages view from the
accessibility hierarchy by marking it as non-important. So, I just
removed the code manipulating [non]importance of the PagedView.
However, this would make the PagesView accessibility-focusable, which is
undesirable. It becomes focusable because it supports long clicks in "normal"
mode. Since it doesn't support accessibility long clicks (i.e. Overview mode is
fetched NOT via accessibility long-click), I just disabled accessibility
long-clickability, which made PageView non-focusable, and it started to behave
correctly.
Bug: 21281859
Change-Id: I7ab01e5f39cb37c456c961199c27458c9bda1c3d
AccessibilityEvent.TYPE_VIEW_SCROLLED sent by PagedView.
This causes an additional reduntant voice message on scroll (see the
bug).
Also, setting these attributes violate rules set here:
http://developer.android.com/reference/android/view/accessibility/AccessibilityEvent.html
i.e. that these fields should be set only for descendants of
AdapterView.
Note that we can't just stop sending TYPE_VIEW_SCROLLED, because in this
case, accessibility focus won't be set after scrolling.
Bug: 21304383
Change-Id: I84f8e064d8209c0e09d6827551e00c9913829b57
Sunny Goyal
Tony Wickham
Adam Cohen
Vadim Tryshev