Status Update
Comments
co...@google.com <co...@google.com> #2
That's working as expected. Let's consult with Javier about his thoughts.
co...@google.com <co...@google.com>
co...@google.com <co...@google.com>
ia...@google.com <ia...@google.com> #3
Did we get any input from Javier for this?
co...@google.com <co...@google.com> #4
The current implementation after the fix is aligned with the foundation API AnchoredDraggable
- I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.
Let me know if you have different thoughts. : )
ia...@google.com <ia...@google.com> #5
I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.
That sounds reasonable to me. Is there a separate bug for that or should I file one?
One thing that I think will be weird is that the size of the panes can come from that anchor or from PaneScaffoldDirective defaultPanePreferredWidth (possibly influenced by the hinge?). In an ideal world, I think we would have the sizes all come from anchors, but that wouldn't work today with three panes visible. I'll add a note to the doc on this.
co...@google.com <co...@google.com> #6
We don't have a separate bug for that but it's already being supported via:
rememberPaneExpansionState(
...
initialAnchoredIndex = i,
)
You raised a very good point about having parallel ways to set up pane sizes.
To me it's sort of reasonable as there are actually referring to different use cases and have different priorities -
- Hinge policies always have the highest priority.
- Pane expansion (and its anchors) are associated with layout splits, but less with the "roles" of the panes that occupy those splits.
Modifier.preferredWidth
always has the lowest priority - more like a fallback default.
I guess we can have more detailed explanation in the doc if this can be confusing?
ia...@google.com <ia...@google.com> #7
Oh, it's in the remember call, perfect!
Yeah, it seems reasonable debating about the use cases, but I worry if it's reasonable for a developer who doesn't consider all that and just wants to show two panes? It's also even more nuanced since 2 only applies for two panes (e.g., if your app shows two panes in portrait on a Samsung Ultra tablet and three panes in landscape). Maybe in the kdoc we should have something similar to what you listed here and in DAC we can provide more context around these.
co...@google.com <co...@google.com> #8
Yeah that sounds good to me. I plan to have some time to refine our kdoc and samples no matter what. Let's maybe work on this in the upcoming alpha/beta period.
Description
Using 1.1.0-alpha01
If you specify anchors with the paneExpansionState, those anchors are only used after the first drag. For example using:
The
anchors on app open.png
attachment shows what this looks like when first opened. Note that the red line indicates a physical hinge on a Pixel Fold and is drawn separate from the scaffold. Theanchors after minimal drag.png
attachment shows what the UI looks like after a minimal drag when the anchors take affect.This is much more noticeable on bigger devices like the Galaxy Tab Ultra line of tablets.
anchors on tablet.mp4
shows what the UI looks like on app open and then drags the handle slightly before releasing to show the snapping behavior.