Skip to content

Make NucleusApplicationScope implement Compose's ApplicationScope#372

Open
kdroidFilter wants to merge 1 commit into
mainfrom
feat/application-scope-implements-compose-scope
Open

Make NucleusApplicationScope implement Compose's ApplicationScope#372
kdroidFilter wants to merge 1 commit into
mainfrom
feat/application-scope-implements-compose-scope

Conversation

@kdroidFilter

Copy link
Copy Markdown
Collaborator

Summary

NucleusApplicationScope now extends androidx.compose.ui.window.ApplicationScope (it already declared the interface's single member, exitApplication()).

Motivation

Libraries whose composables are scoped to Compose's plain ApplicationScope — most immediately the Tray composables in ComposeNativeTray (NucleusFramework/ComposeNativeTray#418, NucleusFramework/ComposeNativeTray#419) — become callable inside nucleusApplication { } blocks with a single overload set. The tray core can then drop its nucleus-application dependency entirely and work in both vanilla Compose application { } apps and Nucleus apps.

Changes

  • NucleusApplicationScope : ApplicationScope (one-line supertype; exitApplication becomes an override).
  • compose.desktop.common moves implementationapi in nucleus-application since the supertype is now public API.
  • The parallel AWT variants of MaterialDecoratedWindow, MaterialDecoratedDialog and JewelDecoratedWindow (receiver ApplicationScope) are now also applicable inside nucleusApplication, and neither signature is more specific (the content lambdas differ). They are marked @LowPriorityInOverloadResolution so the Nucleus overloads keep winning; in plain application { } blocks they remain the only applicable candidates, so behaviour there is unchanged.

Compatibility

  • Source-compatible for normal call sites; binary-compatible (interfaces gain a supertype, JVM signatures unchanged).
  • Third-party code that defines its own parallel ApplicationScope / NucleusApplicationScope overload pairs could hit the same ambiguity and would need the same annotation — considered unlikely.

Verification

  • :nucleus-application, :decorated-window-material3, :decorated-window-jewel build green.
  • Validated end-to-end against ComposeNativeTray: with a locally published 2.1.4, the tray core compiles with ApplicationScope-scoped Tray overloads and no nucleus-application dependency; the demo (nucleusApplication + MaterialDecoratedWindow + Tray + TrayApp) compiles and its overloads resolve to the Nucleus variants.

…pplicationScope

Lets libraries scoped to androidx.compose.ui.window.ApplicationScope (e.g.
ComposeNativeTray's Tray composables) work inside nucleusApplication blocks
without Nucleus-specific overloads, so they no longer need to depend on
nucleus-application at all.

The parallel AWT variants of MaterialDecoratedWindow / MaterialDecoratedDialog /
JewelDecoratedWindow become applicable inside nucleusApplication too; they are
marked @LowPriorityInOverloadResolution so the Nucleus overloads keep winning.
compose.desktop.common moves to api since the supertype is now part of the
public API surface.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant