Skip to content

singleWindowApplication content now receives ApplicationScope too#2703

Merged
Alexander Maryanovsky (m-sasha) merged 4 commits into
jb-mainfrom
m-sasha/add-singleWindowApplication-appScope
Jan 22, 2026
Merged

singleWindowApplication content now receives ApplicationScope too#2703
Alexander Maryanovsky (m-sasha) merged 4 commits into
jb-mainfrom
m-sasha/add-singleWindowApplication-appScope

Conversation

@m-sasha

@m-sasha Alexander Maryanovsky (m-sasha) commented Jan 20, 2026 •
edited
Loading

Copy link
Copy Markdown

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.

@MatkovIvan Ivan Matkov (MatkovIvan) changed the title singleWindowApplication content now receives ApplicationScope too. singleWindowApplication content now receives ApplicationScope too Jan 20, 2026
igordmn
Igor Demin (igordmn) approved these changes Jan 20, 2026
View reviewed changes

@igordmn Igor Demin (igordmn) left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs 2 approvals

MatkovIvan
Ivan Matkov (MatkovIvan) approved these changes Jan 20, 2026
View reviewed changes
Comment thread compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/window/Window.desktop.kt
@Deprecated(
level = DeprecationLevel.HIDDEN,
message = "Replaced by override that takes a `SingleWindowApplicationScope`"
)

@MatkovIvan Ivan Matkov (MatkovIvan) Jan 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Alexander Maryanovsky (m-sasha) Jan 21, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Ivan Matkov (MatkovIvan) Jan 26, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Alexander Maryanovsky (m-sasha) Jan 26, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@m-sasha Alexander Maryanovsky (m-sasha) Jan 26, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Ivan Matkov (MatkovIvan) Jan 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@m-sasha Alexander Maryanovsky (m-sasha) merged commit c48766b into jb-main Jan 22, 2026
21 checks passed
@m-sasha Alexander Maryanovsky (m-sasha) deleted the m-sasha/add-singleWindowApplication-appScope branch January 22, 2026 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@MatkovIvan Ivan Matkov (MatkovIvan) MatkovIvan approved these changes

@igordmn Igor Demin (igordmn) igordmn approved these changes

Assignees

No one assigned

Labels

changes in API

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@m-sasha @MatkovIvan @igordmn