In onBlockTouchUp, if DisplayTopology.rearrange happened to revert the
change made by the drag so that it matched the before-drag layout, the
blocks would not be moved, so the block would be in the dragged position
but not the normalized position.
This will happen when rearrange has a bug or is otherwise optimizing the
layout, which is dependent on the implementation of rearrange.
The test field mTimesReceivedSameTopology has been replaced with one
that represents an observable positive operation:
mTimesRefreshedBlocks, the validation of which has been added to some
existing tests.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Test: move display so that rearrange reverts the change, then exit and re-enter the external display fragment, and verify it matches the state when left
Test: DisplayTopologyPreferenceTest
Bug: b/394361999
Bug: b/394355269
Change-Id: Ic3028747d283db77f144831352b7687fe2706391
A recent CL added a feature to prevent the pane height from shrinking to
stop widgets from moving around. This is actually not a great experience
because a temporary state can keep the pane height very tall and
increase scrolling.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352648432
Test: change topology to be vertically shorter and verify the pane height shrinks
Change-Id: Ic48bfecea083a45c702c8719e3c93ceba55ae872
Simplify the scaling parameters and algorithm and reduce vertical
padding.
Originally a maxBlockRatio was specified at .12, which would have
caused a block length to typically be 2560 * 0.12 = 307. However, this
fails to account for smaller displays and high-DPI displays which have
smaller dip dimensions. So instead choose a maximum edge length of
256dp, which I have found to give good results on a laptop device
and a high DPI tablet, and which does not assume typical sizing for
configured displays, and still accomplishes the purpose of limiting
scrolling and dragging size.
Using the aspect ratio of the display bounds in setting the height
frequently caused a very large amount of padding, and limiting based on
the max block height only reduced it slightly. Now we set the vertical
height based on the minEdgeLength. This length is considered the
smallest size that can be comfortably interacted with, and we use it to
give ballpark ideal padding size.
Note that the unit test cases have increased pane height but in
practice (real-world pane width and constraints) this change seems to
decrease the pane height in general.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Test: atest DisplayTopologyPreferenceTest.kt
Test: atest TopologyScaleTest.kt
Test: compare appearance on mid-dpi and high-dpi screens with a single 1080p external display, or with two external displays of smallish logical size
Change-Id: Id189892c88a1e833c1f54b0e5447a15f92e3310f
Account for high DPI screens in topology pane scaling.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Test: atest DisplayTopologyPreferenceTest.kt
Test: atest TopologyScaleTest.kt
Test: compare appearance on mid-dpi and high-dpi screens with a single 1080p external display
Change-Id: I192fccd402c20e00beacdb5ad55eed406252eb93
In the process of adding highlight we use an extra feature of
LayerDrawable to add insets so that we can add padding without changing
the actual dimensions or position of the DisplayBlock Views.
To make it easier to keep the values consistent and to aid in conversion
between px and dp, use dimen values to store padding and highlight
metrics.
Bug: b/352650922
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Test: atest DisplayTopologyPreferenceTest.kt
Change-Id: I51ff2ce4a086e84a0c529346f8ede90430090b11
Changing the height of the pane causes UI elements below it to shift
around. Allow it to grow when needed but do not shrink once it has
grown.
Test: atest TopologyScaleTest.kt
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Change-Id: I1a3e0ab77b05c5a4337e3e8ab865a974eb1faeda
Add a mirror/extend built-in display switch. Make minor changes to
DisplayTopology.kt for consistency and correctness.
Kotlin requires the two preference key names are different since they
are in the same namespace, so fix the name in the existing
DisplayTopology.kt module.
Make DisplayTopologyPreference responsible, rather than the caller, for
setting its persistence property, since a wrong value may cause unusual
behavior.
The setOrder calls are necessary to prevent the new switch from
appearing below the Built-in display category when a display is
hot-plugged in after showing the UI. We set them on all top-level
preferences (not just the two we are fixing) for consistency.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Test: atest ExternalDisplayPreferenceFragmentTest.java
Bug: b/352648432
Bug: b/366056921
Change-Id: Ib0072dd75066758903cc48c2d1e7142e1d921f67
When dragging a single display, we don't constrain the position of the
display, and the user can drag it anywhere on the fragment. As such we
need to either prevent the drag or refresh the pane always if there is
only one display. This CL chooses the former.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Test: atest DisplayTopologyPreferenceTest.kt
Bug: b/352650922
Change-Id: Icb101b734ce9b88435f64a71bf77f878f9b230e0
If some other app or the system changes the topology, we detect it and
refresh the topology pane. If the listener reports a topology that we
just applied, do not actually refresh the pane.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Test: atest DisplayTopologyPreferenceTest.kt
Test: with added logs, verify that a detach and re-attach w/o new topology does not cause a full refresh
Change-Id: Iecf50d563b430755c93bee5a1ff54f3f3d6eb3da
Use Float rather than Int for View coordinates as mostly Floats are
required. Also stop requiring Point/PointF boxing of arguments, since
the Preference implementation ended up not using Point/PointF objects
very much.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Test: atest DisplayTopologyPreferenceTest.kt
Change-Id: Iecccb9d524014c3b6ad600f99b9e769418e57a4d
After dropping, apply the new topology to the DisplayManager. We assume
the new topology is immediately written and read it back.
We don't yet respond to updates of the topology from other apps or
components; this will come in a follow-up patch soon.
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352650922
Test: drag a display when there is only one in the topology
Test: drag a display when there are two in the topology
Test: close and re-open settings to verify a topology is persisted
Test: atest DisplayTopologyPreferenceTest.kt
Change-Id: I26aa7325570c5fd3e8b5fb60cb6e1196f8657b80
Populate the topology pane with the topology as returned from
DisplayManager.
This adds padding but not the proper rounded corners or highlighting for
the blocks. That will come later, probably after feature complete while
still in dogfood.
Test: add and remove overlays while external display fragment is shown - verify pane is refreshed
Test: add two overlay displays, verify two blocks appear in pane with system wallpaper
Test: with no freeform window displays, verify a "not enabled" message appears in pane with no display blocks
Test: DisplayTopologyPreferenceTest
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352648432
Change-Id: Ibb35af53c24d6feb1d763e4b2bf2ec9fee2ae24d
The original settings of 48 and 0.05 resulted in very small results in
real-world use. The min edge length of 48 does not account for possible
padding and is unnecessarily small. The block ratio of 0.05 is probably
OK to exceed, and is unnecessarily limiting. It is worth noting that the
previous defaults usually caused a conflict between the min length and
max ratio.
Keep the parameters in case we change our mind later.
Test: TopologyScaleTest
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352648432
Change-Id: If8f72dd2e0652ffb33f3d61b137ac7d64a4477f5
In the original design, we don't allow the vertical padding to be more
than the tallest display block on the top or bottom. This patch simply
applies that strategy that was in the design.
Test: TopologyScaleTest
Bug: b/352648432
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Change-Id: Icd3e0c93e4201d8251de0be4ca636352115c657d
TopologyScale helps to size the topology pane and properly size and
place the display blocks inside it. It is based on the algorithm
described in the design doc.
Test: TopologyScaleTest
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Bug: b/352648432
Change-Id: I8932e80c2b490fab0097fa315e536b292376d4a8
Show an empty topology pane in the extended displays list. Even show
when no external display is connected.
This will be tweaked in a follow-up CL to include the built-in display
in the pane and the displays list.
This fixes an issue where the displays list is not shown when *no*
external displays are connected, which was not the intent of the flag.
The previous flag CL ag/30358161 only respected the flag when 1 external
display was connected.
Based on mocks at go/al-mm-figma
Bug: b/352650922
Test: reboot with zero displays attached and verify display list and pane are shown
Test: on al-13 device, make the activity fullscreen and verify the margins on left and right of pane are larger
Flag: com.android.settings.flags.display_topology_pane_in_display_list
Change-Id: If39fefe943a26c817fa6f636f21eb8aaa080adde
