We need to be consistent with the current names, even if they aren't good.

The current name for creating ComposeWindow is also Window:

I.e., at the moment there are 2 Window - one tries to hide ComposeWindow as implementation details, one is an additional overload, specifically for ComposeWindow. In this PR we add one more overload for it.

I thought about it, but

1. From experience, it becomes very confusing to select the right overload. It's already pretty confusing with the overloads we have.
2. I would also like to strongly indicate to the user that this is an API that is lower-level than Window.
3. Having Window for creating ComposeWindow, as you mentioned yourself, is possibly a mistake. We would prefer Window to be an API that's not tied to AWT (except it's too late now).

As an existing example, we have AwtWindow...

Having Window for creating ComposeWindow, as you mentioned yourself, is possibly a mistake.

It was about FrameWindowScope.window available in the AWT-independent arguments overload.

The another overload that has create, update, dispose tied to ComposeWindow is intentional and isn't a mistake. For example, we could add a JavaFX overload:

Overall, consistency is more important than the right names.

If we want the right names, we also need to rename Window(create= to ComposableJFrame, and ComposeWindow to ComposeJFrame, with deprecation of the old names. We can do that, but we should do that in a separate PR.

As an existing example, we have AwtWindow...

It is a mess, but the new function is related to the function I posted in the screenshot, not to AwtWindow

Having 2 functions with just one additional argument isn't good for maintenance.

The semantic of these functions is the same. It is only the parameter init is different.

Better to add init to the original functions, and add an old method with Deprecated(HIDDEN) for backward compatibility.

From our discussion, I thought we agreed that we want to give indication to the user that this is a lower-level, AWT-specific API. I specifically don't want to expose the user to init, unless he has a specific need to go low-level.

Actually, may be I am wrong. If, for example, we wanted to add JavaFX window overload, we couldn't do that 🤔. Will think

that we want to give indication to the user that this is a lower-level

In my thoughts, this is not a question about if the function is low-level, it is only about the specific argument init that is low-level. Either way if we have 1 or 2 functions, we have to describe all that only in the init parameter description.

Actually, may be I am wrong. If, for example, we wanted to add JavaFX window overload, we couldn't do that 🤔. Will think

Ok, I am definitely wrong wanting init in the main function, as:

• it is tied to a specific implementation
• we might want to add another implementation.

So, let's keep separately, as you have.

But let's add a link to a new function in the main function in // comment, so developers don't forget to add new parameters there.

What's the semantic difference between init and create here? Cannot be init just a part of create?

There's a difference both in the intent and in the behavior.

The intent is that configuration (init) is separate from creation of the window.

The behavior is that init is called after all the "create" parts completed. It can't be folded into create itself because create is called first, then this function does stuff (setting rootForTestListener etc.) and then init is called.

I don't fully follow why it cannot be folded and why setting listeners should be done before "init"

Can we keep this reverted dependency to avoid replicating AWT/Swing API? I mean providing overload to receive AWT/Swing object outside (or lambda factory) and deal with already constructed/initialized object here?

I don't fully follow why it cannot be folder and why setting listeners should be done before "init"

I don't think it actually does matter now, but it could matter in the future. That code may want to set some property of the window that the user may want to override, so its best to first call all of our code, and then the user code.

It's not a big deal, but I think it would actually be best to refactor this:

1. Add an init argument to AwtWindow.
2. Move all the code configuring the window into init, leaving only the creation itself in create.

@igordmn What do you think?

I don't think it actually does matter now, but it could matter in the future.

For me init was always part of creation process, unless something else is specified initContext(adapter), etc.

Having both init and create: () -> is confusing for me.

That code may want to set some property of the window that the user may want to override, so its best to first call all of our code

What is set inside AwtWindow/SwingWindow (rootForTestListener, compositionLocalContext, exceptionHandler, and isVisible) is either needed for proper work of these Composable, or is read from the outside world (from locals). So, either it is wrong wanting to override the properties (it breaks the Composable), or there is another way (override the locals). All other types of properties shouldn't be set inside these functions.

What is set inside AwtWindow/SwingWindow (rootForTestListener, compositionLocalContext, exceptionHandler, and isVisible) is either needed for proper work of these Composable, or is read from the outside world (from locals).

That's true now, but won't necessarily be true in the future.

Anyway, I don't have a strong conviction about this, so I'll fold init into create if you both think it's the right choice.

but won't necessarily be true in the future.

I wrote that it shouldn't be true:

All other types of properties shouldn't be set inside these functions.

If we add such properties, it will be a mistake.