Instead of using hard-coded variants of colors, use the theme color
that corresponds (colorAccent, colorPrimary, etc).
Updated:
- "Search for more apps" text
- App info drop target hover color
- PageIndicatorDots
- All apps & widget scroll bar & scroll popup colors
- All apps section text color
- widget picker background color
TODO:
- widget picker header color
BUG: 28625102
Change-Id: I74b543ff71b8caef8cd950c8183ac84c759cb4d5
> This used to work, but when I got rid of preloading which was
handled by linear manager to increase scrolling speed, the save
and restore instance that was being handled by the linear layout
manager created using Launcher context also went away. Hence,
bringing back custom LinearLayoutManager.
Change-Id: Ibccdf80533a5ace06cc6c6932b257c223cbac0ff
> Instead of handling insets in BaseContainerView, directly applying
them to margins, as that scpace can't be used for scroll handling
> Appliying the top and bottom padding in xml
> The left & right padding is defied in xml which is reused for scroll
handling
Bug: 27108154
Change-Id: Ia32e6d5e8fd1bfafb1d77d1244ce2268e4da9df9
b/27380335
padding was set wrong when the widget view hierarchy was
being refactored in this CL: ag/870011
Change-Id: I003634acded2bbe204098c0e6fefff13d154b5d6
Widget is loaded only when the user enters the overview mode and we keep
the list updated as long as the user is in the overview mode. Once the user
leaves the overview mode, we stop responding to widget updates
Bug: 26077457
Change-Id: I9e4904b8f1300bfe0d77e2bc5f59aa6963fad8d1
-> 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
The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
- Reuse DeleteDropTarget since it's the same effect, but with "Cancel"
instead of "Remove" if supportsDeleteDropTarget() returns false.
- Rename related strings (but not their values)
Bug: 24104015
Bug: 24099531
Change-Id: Ia9fbcaa17bb17f7aa31df1f830298da01544c178
- This CL fixes an old assumption we had about the height
of rows in AllApps, and ensures that we account for the
difference in height between the predictive icons and the
normal icons.
- In addition, we refactor FastBitmapDrawable to have multiple
states, which it manages in drawing itself, including the
press state and fast scroll focus states. And we also refactor
some of the fast scroll logic in the all apps recycler view
out to its own class.
Change-Id: I1988159b2767df733bbbfc7dc601859cde6c9943
1) Use a different content description for temporary new page
2) Use different accessibility description for add widget toast
3) Announce when an item is deleted
4) Announce when hovering over a drop target
5) Announce state during drag-n-drop and widget resize (similar to seekbar)
Bug: 23573321, 24057944
Change-Id: Icabb317625e70c78e11c0b4f99b9339172d93594
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
- The regression was introduced in scroll bar changes ag/751628, but
unlike AllApps, the WidgetsRecyclerView can have an unbound model.
Bug: 23689784
Change-Id: Ibd3d5bcbafab0ada9a372fa00acaa45809ce720d
This will enable an easier migration to the new M APIs for identifying
button presses from stylus / other tools.
Bug: 20430722
Change-Id: I41cfa6eff8d76bb83cf1bdaf6623ec1092ed554c
> Removing utility method for isAttachedToWindow
> Moving logic to calculate cell size from workspace to DeviceProfile
> Replacing some constants with xml resource variables
> Saving the item info using content values for better compatibility with other methods
Change-Id: Idd612633d97a6241cb31148df9466031374bd5a0
- Issue: The fast scroller currently does not follow the touch input
because fundamentally, the fixed scrollbar height and the mapping
of the scroll space to the scrollbar space is fundamentally incompatible.
- This CL changes the fast scroller to allow it to detach when the user
fast-scrolls, then re-attaches after the user scrolls the screen and
the current scroll position for the scrollbar picks up the thumb position.
- Since the scroll position and the fast scroller thumb is now detached,
we can change the distribution of the fast scroll letters to make it
independent of the rows for each section and instead uniformly distribute
it along the scrollbar, which allows for more stability.
- There are edge cases where this fails, especially when there are few
apps, which we can investigate further.
Bug: 20035978
Change-Id: I8322f862107e6f330deff692885233706564bffd
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
Andrew Sapperstein
Sunny Goyal
Hyunyoung Song
Adam Cohen
Tony Wickham
Winson
Mady Mellor
Vadim Tryshev