In ag/1460444 we used TransformingTouchDelegate to extend the
touch target for the widgets list. Now both WidgetsContainerView
and AllAppsContainerView will use the same TransformingTouchDelegate logic
to extend the touch target for their respective lists.
This is part of a larger refactor where in a follow up CL, we will
handle the logic for dismissing WCV and AACV when touching outside
of its content in BaseContainerView. (currently broken in WCV).
Change-Id: I7fddb456bba34a6533f8824da0481d308a8b715e
The widget row contents were being clipped, which made it seem like
the horizontal scroll was broken.
Bug: 30023607
Change-Id: I00b0c334bbb0faf166d4cd168392cc494ed732e0
b/30039490
Supported in this CL:
- DnD: drag from container [WORKSPACE|HOTSEAT|FOLDER|ALLAPPS|WIDGETS|DEEPSHORTCUTS]
drag to container [HOTSEAT,WORKSPACE,FOLDER,DROPTARGETS]
- Source and target can be [FOLDER_ICON, ICON, DEEPSHORTCUT, WIDGET]
- $ adb shell setprop log.tag.UserEvent DEBUG will turn on debugging
Change-Id: I0b8b879b80e6dce85bbde6e7794f9e0677832603
(cherry picked from commit 59a238095e)
1) Adding DragOptions to easily extend drap functionality
2) Changing onDragStarted signature to send more information
3) Updating states for dropTargetButton based on drag event directly
4) Removing folder item based on onDragStarted and not startDrag
Change-Id: I65b684e092ddc081d086bfe2c8c1973ed170eaeb
b/30039490
Supported in this CL:
- DnD: drag from container [WORKSPACE|HOTSEAT|FOLDER|ALLAPPS|WIDGETS|DEEPSHORTCUTS]
drag to container [HOTSEAT,WORKSPACE,FOLDER,DROPTARGETS]
- Source and target can be [FOLDER_ICON, ICON, DEEPSHORTCUT, WIDGET]
- $ adb shell setprop log.tag.UserEvent DEBUG will turn on debugging
Change-Id: I0b8b879b80e6dce85bbde6e7794f9e0677832603
This will allow drag controller to optinally defer drag, based on some
threshold, by simply deferring the callback onDragStart
Change-Id: I17c06a15e2092b9797c7e57529b12a53d2acae6e
- Adding DeviceProfile callback for when the launcher layout changes due
to insets. This is necessary since there are now different layouts
depending on which side the navigation bar is on
- Consolidating hotseat and other layout into the device profile
launcher layout logic
- Making the all apps icons match the workspace icon height
- Tweaking caret drawable to draw to the bounds specified to simplify
layout in each orientation
- Fixing minor issue with page indicator shifting in landscape
- Centering overview buttons to the workspace page
Bug: 30021487
Change-Id: I1866bce00b2948f3edd06168c0f88d81207e3f13
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
> 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
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
> 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
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
> Filtering the widget list and excluding widgets which dont fit the grid
> setting minSpans for the widget item when binding.
Bug: 22541314
Bug: 22559137
Change-Id: Ieda48b56c95bee0c7ec71dd691af7e23e2d43db6
> Changing dragObject to ItemInfo
> Removing dropPos which is always null
> Removing requiresDbUpdate which is only used in CellLayout
Change-Id: I753ddaae0880c8a9bfee5a1266095ff34610284a
- Fixing issue with fast scroller not fitting name width.
- Refactoring fast scrolling/scroll bar code out of base recycler view
- Adding animations to fast scroller to match design
- Smooth scrolling when jumping between app rows
- Fixing issue with fast scroller jumping when you first pick it up
- Fixing issue with wrong background paddings being used
Bug: 21874346
Bug: 22031923
Change-Id: I9f011b1f375751f437604b900e95a2942d3f4601
- Adding support for an external search bar that can be used
to search a container view. This adds a new interface
AllAppsSearchController which manages the external search
bar. Each controller will have its own search implementation
which means that we no longer need a common AppSearchManager
interface.
- Removing elevation controller as we no longer have a builtin
search bar in all apps
- Refactoring container view insets so that they behave
the same in all containers.
- Refactoring apps view to ensure that we only update the number
of columns with the available width
- Cleaning up LauncherCallbacks interface
Bug: 20127840
Bug: 21494973
Change-Id: I710b8e18196961d77d8a29f0c345531d480936fe
> Using a single bitmap icon size
> Picking up appropriate density for satisfy the required icon size
> Fixing some icon size assumptions during icon animations
Bug: 19514688
Change-Id: Ia7a1d0d2c03a9d39ccc241fa4ae3eb8a0f374585
> The preloaded widget was being set in a different instance of
PendingAddWidgetInfo and was never getting used for animation.
bug: 20699153
Change-Id: Iaec13640e49c66993b4695e4a52dc3a3a2133fb2
> Make package-private and @Thunk all private methods and constructors accessed from inner classes.
Change-Id: Ie5913860a0c33e48e9bf68f9b5b1699f64c2f174
- This change has no effect on actual functionality but to make it easier
for widget tray to inherit the goodness of the 1) fast scroller
functionality 2) unify the scroll look and feel with the all apps view
b/21375339
Change-Id: Ib859b1c3352c0b69f16549ded8f20eb82cf58ba8
> Adding empty page synchronously, instead of waiting for a frame
> Changing launcher state from widgets screen in the same frame, similar to all apps
> Removing DragEnforcer, and moving that logic in side the workspace, disabled by a flag
> Using first page to get page bounds in drag layer, as last page may not have been measured
Change-Id: I172ba4e5ce44648ac55402d49994542c6e10f101
-> Pulling out the parts of device profile which can (and need to be)
initialized and accessed without access to an Activity context,
ie. the invariant bits.
-> The invariant bits are stored in InvariantDeviceProfile which is
initialized statically from LauncherAppState.
-> The DeviceProfile contains the Activity context-dependent bits,
and we will create one of these for each Activity instance, and
this instance is accessed through the Launcher activity.
-> It's possible that we can continue to refactor this such that
all appropriate dimensions can be computed without an Activity
context (by only specifying orientation). This would be an
extension of this CL and allow us to know exactly how launcher
will look in both orientations from any context.
Sets the stage for some improvements around b/19514688
Change-Id: Ia7daccf14d8ca2b9cb340b8780b684769e9f1892
- Decoupled widget model from widget view, and placed the
creation to LauncherModel.
- As a result packagemanager operation, iconcache retrieval is all done inside
LauncherModel on background thread
b/21311085
b/21325319
Change-Id: I294698527db58b89f3da558090a367530c058776
