I'm trying to workaround some limitations in the e...

# compose

[Andy Himberger]

I'm trying to workaround some limitations in the experimental material ModalBottomSheetLayout.
Since this composable doesn't actually use Dialog like the view based materal BottomSheetDialog, we're not getting the automatic OS behavior to size and position the bottomsheet. (On Surface Duo devices bottomsheets don't span both screens obscuring content in the middle, instead they get positioned on the screen to the right when you app is spanned across both screens). I'm guessing the foldable device case will get handled by material library someday (though the androidx.window library is maybe not very convenient for a library to use with its async API to detect foldables), in the meantime, what would be a good workaround?

(We have another case I guess Material won't care about, but we like to not use full width bottomsheets on really big displays)

I've tried two things:
(1) create a wrapper that replaces part of ModalBottomSheetLayout so I'm doing my own background Scrim and display of the content, then size/position a ModalBottomSheetLayout inside of that. Because Scrim() and ModalBottomSheetState.confirmStateChange are private in material, I have to duplicate a bit but not too much to get something that looks and behaves correctly.
(2) set sheetBackgroundColor, elevation to be invisible, on my sheetcontent specify the background color, elevation, shape. This looks right but the interaction is a little wrong since you can swipe on transparent areas of bottomsheet content.

I suppose another option is to use the view based BottomSheetDialog and setContent a separate compose tree there. or try to recreate ModalBottomSheetLayout using compose's Dialog infra. Other ideas?

[Colton Idle]

jossiwolf might have some ideas?