Rename desktop's Dialog to DialogWindow

[MatkovIvan]

Proposed Changes

• Rename existing Dialog function to avoid same naming with commonized Dialog
• See Expect Dialog in common #632 (comment)

API change

- androidx.compose.ui.window.Dialog(onCloseRequest, state, visible, title, icon, undecorated, transparent, resizable, enabled, focusable, onPreviewKeyEvent, onKeyEvent, content)
+ androidx.compose.ui.window.DialogWindow(onCloseRequest, state, visible, title, icon, undecorated, transparent, resizable, enabled, focusable, onPreviewKeyEvent, onKeyEvent, content)

Testing

Test: N/A

[igordmn]

We need to discuss that online with @m-sasha

[m-sasha]

Maybe call this PlatformDialog? We could even make it a policy to call "native" widgets wrapped in a Composable PlatformWidget.

[igordmn]

Naming it to PlatformDialog also looks good at the first glance. But at the second glance, we have to think significantly more:

• about renaming Window -> PlatformWindow
• about renaming MenuBar -> PlatformMenuBar
• about renaming DialogWindowScope -> PlatformDialogScope
• about creating PlatformPopup
• does it make sense to create PlatformTextField instead of UIKItTextField on iOS
• does it make sense to create PlatformTextField instead of SwingTextField. What will be used when we run tests, integrate into Fleet, or replace Swing by LWJGL?
• Should we make LocalPlatform.platformDialogFactory, which affects PlatformDialog or not? What if we decide in the future that common Dialog should be also affected by LocalDialogFactory?
• does this code look good:

fun main() = application {
   PlatformWindow {
      PlatformMenuBar {

      }
      if (dialogVisible) {
         PlatformDialog {

         }
      }
   }
}

If we just rename to DialogWindow we don't have to think about all of that now.

[m-sasha]

The problem with DialogWindow is that it's too generic/abstract. The name doesn't hint at its uniqueness/how it's different from Dialog.
But, you're right, PlatformDialog is still too generic because it's not entirely clear what platform it refers to.
But, if we're doing UIKitTextField and SwingTextField then the dialog here should be SwingDialog. That seems to say exactly what it is.

[igordmn]

then the dialog here should be SwingDialog

It violates the current strategy of the window API - hide Swing as implementation details under the API and provide one small interop scope.window, which can be deprecated or renamed to an extension swingWindowOrNull similar to event.awtEventOrNull

[igordmn]

A lot of questions :)

The problem with DialogWindow is that it's too generic/abstract.

The same as with Window, application. It is on purpose.

[igordmn]

It is on purpose.

There are 2 reasons:

• provide a simple DSL for creating a generic application
• hide Swing implementation details, so we can replace it in the future (as said above)

May be it was a mistake to allow defining the platform Dialog anywhere in the composition, not only in ApplicationScope/WindowScope. But I can't say for sure yet.

[igordmn]

@m-sasha, will it be okay in the current state?

[m-sasha]

If the goal is to hide the implementation then I guess I don't have a better suggestion for a name.

[MatkovIvan]

If the goal is to hide the implementation

Not to hide but to distinguish in-window and on-canvas implementations

[igordmn]

Not to hide but to distinguish in-window and on-canvas implementations

The goal behind naming Window/DialogWindow instead of SwingWindow/SwingDialog is to hide details. See the messages above

(but distinguishing is also the goal, yes)