This is because there is no click action for CellLayout during accessible drag, as only the individual cells need to be clickable.
Bug: 318312177
Test: locally
Flag: N/A
Change-Id: I26f18a948b77a0ee889dfafa626b9176d8481aeb
This will make it easier to test CellLayout, also we should avoid
circular dependencies as much as poisble.
This also allows the CellLayout to be created in other containers
that are not workspace.
Bug: 318417510
Test: creating HotseatReorderUnitTest in follow up cl
Test: TaplReorderWidgets
Test: ReorderAlgorithmUnitTest
Flag: NA
Change-Id: Ic45029a244cb11f8d6775c50b90af9c56f01eaa3
The animation ReorderPreviewAnimation handles two animations, one when
the mode is MODE_HINT and the other MODE_PREVIEW. The animation is
basically the same but MODE_PREVIEW ocilates to finalDelta and back
to initDelta. MODE_HINT stays in finalDelta. When finish, we have to
go back to the initial position.
This behaviour is currently done using logic, making sure the view stays
in finalDelta no matter the value of the animation, the bug is in this
logic. I think is better to do this with the current animation API by
setting setRepeatCount to 0 on the HINT case and reverting the animation
when finish so it goes back to the initial position.
This seems to have been there for a long time, at least since the
creating of git_main, but it became more aparent now. In a follow up cl
I will move this class to it's own file and into kotlin to help if there
are issues here again.
Fix: 294473336
Test: manual testing
Flag: NA
Change-Id: I4ac5de3ce8a8170944a072c6ce41c65d0963a780
This is a no-op thoroughly tested by ReorderAlgorithmUnitTest.
Flag: NA
Bug: 229292911
Test: ReorderAlgorithmUnitTest
Change-Id: I7203444df289cd3b67794fc570a2cd46e64549a2
This is a no-op thoroughly tested by ReorderAlgorithmUnitTest.
Flag: NA
Bug: 229292911
Test: ReorderAlgorithmUnitTest
Change-Id: I9909477274aadbbf928c9fdeb4157d697c4c7175
Also, simplify copyCurrentStateToSolution since it always gets false
as the second parameter.
Flag: NA
Bug: 229292911
Test: ReorderAlgorithmUnitTest
Change-Id: I025566897246fa59ca513cb7de9a12465054498f
This is a no-op change ensure this we have ReorderAlgorithmUnitTest.
Flag: NA
Bug: 229292911
Test: ReorderAlgorithmUnitTest
Change-Id: I6ffe2a1260f869a4686a9f1e652dd1ab6d406269
Using cellToRect and removing some calculation that where unnecesary
because the variable are later overwritten.
Fix: 194414754
Bug: 294841331
Test: ImageTest
Change-Id: I31e0527cbbea463a32a36a172185a41985ed0d57
Include change for setting the hover state flag programatically, as FastBitmapDrawable does not currently support DeviceConfig flags.
Fix: 243191650
Test: FastBitmapDrawableTest. Screenshot tests in another cl.
Flag: ENABLE_CURSOR_HOVER_STATES
Change-Id: I0eb796ae62e571a3287132bfcb99c4fca1e2fbe4
Changing the grid while a previous loader is running (more likely to happen in test) can cause a saved item info to have a cell position outside the bounds of the new grid. This should just be handled the same way as other item infos being loaded in an occupied space.
Flag: not needed
Fixes: 233989158
Test: changed grid sizes multiple times
Change-Id: Ibba337c224e7a08533331a87b1369ebf96e3c9a3
It uses the new responsive folder calculations and specs when responsive grid is enabled. The grid has to have folderSpecsId defined to use the new specifications, otherwise it will use the current scalable grid implementation.
Fix: 284155638
Test: DeviceProfileDumpTest
Test: ResponsiveHomeScreenFolderImageTest
Test: HomeScreenFolderImageTest
Flag: ENABLE_RESPONSIVE_WORKSPACE
Change-Id: I535cff4bb00e969f782447a898230fe2b2c05cc9
In the other method createAreaForResize we add 1 to the cellX
to account for the seam in the Multipace CellLayout but we don't
account for that on performReorder and we need to add a cellWidth
Also, some methods are not running when the seam is added so their
result are wrong. Now all methods are being accounted for.
Fix: 277709417
Test: atest ReorderAlgorithm
Test: atest MulticellReorderAlgorithm
Change-Id: I7a4ca55f7b9cd7cf94481c880fe152e0a3bb3cf3
- Edit Mode doesn't close after dragging / dropping an app
- Edit Mode can be entered through options popup menu, Spring Loaded still entered by dragging items
- Adds new onLeavingState call to launcher states to cleanup changes
Bug: 279590398
Flag: MULTI_SELECT_EDIT_MODE
Test: manually tested the new state with flag on/off
Change-Id: If4550037f9659dcb8cd8b1943388d1ec5d55fa29
Adding 100 different test cases for the ReorderAlgorithm.
The test cases are randomly generated using generateRandomTestCase()
the boards are generated once and then written in the file
reorder_algorithm_test_cases. I will leave the code to generate
the boards in the Test even though is not used anymore in case
we need to generate more boards later on.
Also, I found that the ReorderAlgorithm was not deterministic,
meaning that it could generate two different results with the same
inputs (views positions and view being drag positions), because
it was traversing a map whose has was the object id which is
random. So I sort the views before traversing them.
Bug: 229292911
Test: atest ReorderAlgorithmUnitTestCase
Change-Id: I196eb8f1dafcb57d5259969268c458129ae4f46b
We previously made a few CL's guarded under flags for the multi select feature. We ended up having to halt progress on this, and now that we're starting again, the design is different and we are using a new flag. Here we get rid of the unused code and flags
Bug: 277617038
Test: Verify everything still works normally, everything was guarded under flags that were off so there shouldn't be any changes
Change-Id: I2f57d1f67aa2a8cf83287f6f3df9fa6c46dbf0ab
We need to change the result of REQUEST_IS_TWO_PANELS when the
flag is on because now we don't have two panels only 1.
Another of the issues is a rounding error when calling
getUnusedHorizontalSpace().
And lastly updating workspaceToBoards so that it maps the coordinate
of workspace items to their right position.
Bug: 270395274
Test: atest ReorderWidgets
Change-Id: I2620e5bf1ba132f984e00d2a6c21081953d259fd
ReorderAlgorithm will now handle all the logic associated with the
reorder. Basically all the logic associated with a reorder in CellLayout
was copy and pasted into ReorderAlgorithm.java.
Test: atest TestReorderAlgorithm
Bug: 229292911
Change-Id: Ie096abc346bf705414e47452a42d1dec5be0a041
Bug: 188081026
Test: no op change, should compile
Test: ReorderWidgets
Change-Id: I20367974e5a4cead406e18eb66dafd4d59651b2a
Merged-In: I20367974e5a4cead406e18eb66dafd4d59651b2a
The previous reorder solution is not peropperly cleaned and
that leads to wrong solution being used. For example when
longpressing an icon, it triggers a drag but the drag never
finishes.
Fix: 261122618
Test: You can no longer overlap a shortcut in the same app icon (see attached bug)
Test: atest ReorderWidget
Change-Id: Iff8651926cc4179561761c7ce0ac5007f13fc9af
* changes:
Fixing the revert by not continuing the reorder if the solution is null.
Revert "Revert "Reorder widgets no longer overlaps when no space..."
Revert "Revert "Reorder widgets no longer overlaps when no space..."
Revert submission 20479526-revert-20427045-258023561-BPDASTWITO
Reason for revert: Fix the issue that caused the first revert.
Reverted Changes:
Icecfd1d34:Revert "Reorder widgets no longer overlaps when no...
I4cc552588:Revert "Reorder widgets no longer overlaps when no...
Change-Id: I47c4cde42c19f50e2834660d843a8e2ae571c03c
Revert "Reorder widgets no longer overlaps when no space is avai..."
Revert submission 20427045-258023561
Reason for revert: Likely causing NPE while running launcher shortcut tests (Part of DM+Platinum monitor rotation. The revert won't be submitted if proven otherwise)
Bug: 259234533
Reverted Changes:
Ie599f7cb7:Reorder widgets no longer overlaps when no space i...
I04b262ecc:Reorder widgets no longer overlaps when no space i...
Change-Id: I4cc552588c8099356bc3f05c4c63d17a524f2a24
In the previous refactor I got confused between findNearestVacantArea
and findNearestArea thinking the later did the former. So it ignored the occupied spaces and treat it as a solution.
Changed the names to prevent further confusion.
Fix: 258023561
Test: manual, need to add this case to ReorderWidgets
Change-Id: I04b262ecce168d5c93a9d66ef62d5b0e148e38b6
Design doc: https://docs.google.com/document/d/1RsId9OFGgkcImkkmDwWZBBvITWnGlxKVqniE3cimkqY/edit#heading=h.xzptrog8pyxf
As can be seen in the diagram in b/256770363 on every reorder the
first call in the process is MODE_SHOW_REORDER_HINT so if we make
sure that only then a solution is calculated and we reuse that
solution in the rest of the calls in the same reorder then we would
have more consistency and the animation will always be the same and
the logic state.
Fix: 256770363
Bug: 188081026
Test: atest ReorderWidgets
Change-Id: I93a1d09f5b8cbfbc461043ee3fc41b1cab294fed
Using the stack was more efficient because it prevented the creation
of new rectangles but it makes the code harder to read and prone to
bugs if the global state of the stack of rectangles gets corrupted
in any way.
When this optimization was written in 2008 it was necessary but now I
don't think it would have a big impact. The stack size is on average
of 30 and the rectangles are only created when doing the reorder which
runs about once per second if the user moves the finger too quickly.
Bug: 188081026
Test: atest ReorderWidgets
Change-Id: I35d8ee8d92f01035e72fe5763a7de47f4b6a73de
