To keep this CL small and focused, I'm going to create
a separate CL that handles the scaling for the widget in
drag and drop mode.
Bug: 32176631
Change-Id: Id6557d070edb664aa1f4851de7abf494cf8a0677
* Vertically centers workspace icons.
* New iconDisplay value so shortcut text is not overriden.
Bug: 32176631
Change-Id: I86753bab5b24aafc417e0f77d8c471fc4c0dc7f0
1) setChildrenDrawnWithCacheEnabled: deprecated
2) Removing custom logic based on isHardwareAccelerated. This check was not being
used consistantly everywhere
Bug: 29761236
Change-Id: Ic4a9c764f154497e376e37de2351fe04d1b48500
Also move cleanup (resetting variables to null) to onDragEnd
instead of onDropCompleted. These changes are necessary because
pre-drags (for apps with shortcuts) don't call onDragStart
or onDropCompleted.
Bug: 32246571
Change-Id: Ib18fac64555e9158b776f9c12afc2cb807b3c355
1) Using ALPHA_8 as the start and end bitmap. This removes one extra
bitmap generation step
2) Using ByteBuffer on ALPHA_8 bitmap for clipAlpha. This allows us
to use byteArray instead of intArray for representing pixels
Change-Id: I1b654c439fd491b6b91180ddc562bb97fad857aa
This will allow drag controller to optinally defer drag, based on some
threshold, by simply deferring the callback onDragStart
Change-Id: I17c06a15e2092b9797c7e57529b12a53d2acae6e
This allows better edge matching for the QSB. The QSB position
is kept synchronized with the page scroll and all-apps transition.
But its not visible in spring loaded and overview mode
Change-Id: I4e6723607ea966ee672273a9ca67c792fd6b5661
The QSB will only be resent on the first screen of the workspace
covering the full width of the first row. If will not be movable.
The first screen of the workspace will not be movable.
The searchDropTargetBar no longer contains the QSB (it can be
renamed in aseparate cl).
Refactoring all QSB related logic by moving it to a custom view
inflated only using xml.
Change-Id: Icb4fd6eb855df1af15f685961c38351bf4fd4f4a
It looked weird, because the scrim cutout happens immediately
and the border flickered into place shortly after.
Bug: 27135377
Change-Id: Iff861db73c438c7dabccd6ed7c4ee38dbeb77ea1
-> Don't reuse the same background object for the folder create preview
since this can cause interruptions in the animations for previous
creation previews.
-> When drawing the background to preview creation, don't draw the stroke
above the icon since the icon is not yet contained by the folder.
Change-Id: Ib666dc2453df465b342c02f3bd109b553a769dcc
-> Refactored the preview background rendering to be much more self-contained.
This cleans up a lot of code in the CellLayout, and keeps the logic in the
right place.
-> We switch to software rendering for performance and compatibility reasons.
-> Removed all assets.
-> FolderIcon accept animation includes animation of the clipped region.
-> 1:1 hand-off of drawing of the FolderIcon background between the FolderIcon
and the CellLayout. Unfortunately, CellLayout rendering is still required
to work around clipping issues (due to use of software layer). We also
need this to support folder creation feedback.
Change-Id: Ib8f7fa6359dfedff8145f38dd50ba03849ca0d51
-> 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
- No page indicators in spring-loaded mode
- Don’t move workspace up as high
- Scale workspace at 90% instead of 80% on phones
- Increase speed of workspace -> spring-loaded -> workspace
- Widgets were being scaled down twice when dragging from widget picker
- Don't scale up icons when dragging (scaling other stuff down is enough)
- Make scrim less dark and panels more transparent
- Thin white border around page instead of highlight when hovering
Change-Id: I963e91c20d4c0340480d165e0f3b8064783c0cb2
- Added side hints back
- Only scale down icons if spring-loaded
- Only show App Info drop target if spring-loaded
Change-Id: I4b0dddccbe0e80b7ceb6b7266fc527f757744148
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
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Bug: 16840760
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
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
Since power save mode (introduced in Lollipop, also known as battery saver)
disables animations, the ReorderPreviewAnimation looks bad - instead of
displaced folders subtly and smoothly moving up and down, they violently jump
between up and down positions in rapid succession. Setting the animation to not
repeat in this case avoids this issue.
Bug: 23675090
Change-Id: I8149610af75e7023dca28a942b3447228083cd33
(cherry picked from commit 9e0702f4af)
Since power save mode (introduced in Lollipop, also known as battery saver)
disables animations, the ReorderPreviewAnimation looks bad - instead of
displaced folders subtly and smoothly moving up and down, they violently jump
between up and down positions in rapid succession. Setting the animation to not
repeat in this case avoids this issue.
Bug: 23675090
Change-Id: I8149610af75e7023dca28a942b3447228083cd33
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
This will enable an easier migration to the new M APIs for identifying
button presses from stylus / other tools.
Bug: 20430722
Change-Id: I41cfa6eff8d76bb83cf1bdaf6623ec1092ed554c