Status Update
Comments
co...@google.com <co...@google.com>
co...@google.com <co...@google.com>
co...@google.com <co...@google.com> #2
That's working as expected. Let's consult with Javier about his thoughts.
na...@google.com <na...@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. : )
co...@google.com <co...@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.
Description
When the app is running in a COMPACT area, both List-Detail and Supporting Pane can show either the main
Composable
(List
orMain
) or the additional one (Detail
,Support
,Extra
). When you are in the secondary one and press back, the current behaviour is to pop out of theScaffold
completely, should we add a back handler that when inCOMPACT
would pop the secondary one back to the main one?As an example, could this be the default behaviour?