Why is compose using framework dialogs and popup windows instead of replicate them with composable f...

# compose

[Manuel Wrage]

Why is compose using framework dialogs and popup windows instead of replicate them with composable functions?

[Luca Nicoletti]

It really is not

[Luca Nicoletti]

There are @Composable functions for dialogs

[Manuel Wrage]

I know that i can compose the content of dialogs and popups but the lib uses the native windows and dialogs to display it.

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/ui/ui-foundation/src/main/java/androidx/ui/foundation/Dialog.kt

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/ui/ui-foundation/src/main/java/androidx/ui/foundation/Popup.kt

[Giorgos Neokleous]

There was a similar discussion recently. Dialogs will use the window manager under the hood: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1572469774151700

[Manuel Wrage]

I would like to hear the reason behind it because it could easily be reproduced with only composable functions. I already created popupmenus without native windows.

[Mark Murphy]

it because it could easily be reproduced with only composable functions

I had a discussion in this channel on this topic a month or so ago. Google's argument is that your approach only works if the child "window" is limited to be shown in the boundaries of the parent window. By definition, a window cannot draw outside of its boundaries, which means that a popup drawn by a window cannot go outside of the window. While in many cases that may be acceptable, once you start thinking of freeform multiwindow (e.g., Chrome OS devices), it starts to become a bigger limitation.

[Manuel Wrage]

Thanks for the explanation sounds reasonable. Looks like i will have to write my own dialog thing:D

[romainguy]

Why don't you want to use Windows for those popups?