singleWindowApplication content now receives ApplicationScope too

[m-sasha]

singleWindowApplication content now receives SingleWindowApplicationScope, which is a subtype of both ApplicationScope and FrameWindowScope

Fixes Cannot exitApplication() in singleWindowApplication

Testing

Tested with

fun main() {
    singleWindowApplication(exitProcessOnExit = false) {
        Box(Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
            Button(
                onClick = {
                    exitApplication()
                }
            ) {
                Text("Close App")
            }
        }
    }

    println("Application exited")
}

making sure "Application exited" is printed after pressing the "Close App" button.

Release Notes

Features - Desktop

• singleWindowApplication content's receiver now subclasses ApplicationScope too, allowing to programmatically exit the app.

[igordmn]

Needs 2 approvals

[MatkovIvan]

In general, we don't need to keep compatibility for experimental, but let's keep it for one version.

Please add YT tasks for:

• Remove ExperimentalComposeUiApi/Deprecated override in 1.12
• Stabilize ExperimentalComposeUiApi overrides

[m-sasha]

Is there a need to remove the deprecated version? It's marked as HIDDEN, but provides binary backwards compatibility, so I don't see any harm to keep it.

[MatkovIvan]

The experimental annotation is added to be able to remove/change it in the next version without deprecation/keeping it in the codebase forever. There is no reason to keep it

[m-sasha]

My question was about the removal of the non-experimental overload.

[m-sasha]

Although, actually it applies to the experimental one too.
The reason to keep it is to continue providing binary backwards compatibility. I don't see a reason to not do that.

[MatkovIvan]

My question was about the removal of the non-experimental overload.

We should keep it compatibility/deprecated version for non-experimental variant

The reason to keep it is to continue providing binary backwards compatibility.

It's not an argument for experimental API

I don't see a reason to not do that.

To keep semantics of experimental, to keep our codebase clean.
Also, I don't really see the use case where it might be useful for anybody – the entry point isn't used in libraries anyway