Skip to content

Support the extended fork's GraalVM native-image and Kotlin/Native desktop paths as user choices #191

Open

Description

@b-re-w

What

Support the two extra runtime paths that compose-multiplatform-extended / compose-multiplatform-core-extended provide, as additional choices for users, next to the upstream JetBrains Compose paths that stay the default:

  1. GraalVM native-image desktop app: a single executable with the AWT-free window, input, window chrome and resize finished in the fork.
  2. Kotlin/Native desktop app: the fork's K/N UI targets with window, input and accessibility moved into the fork.

python-multiplatform should be able to support both: the upcall path is a build-time table with no runtime reflection (AGENTS.md §12.3, §13), which is exactly what a closed-world native image and Kotlin/Native need. The native-image upcall entry point is already verified (docs/platforms/graal-native-image-verification.md), but no Compose window runs through native-image today, and desktop K/N has no interpreter target yet.

Work (once the fork ships the paths)

  • Gradle plugin: let an app choose upstream Compose (default), extended GraalVM, or extended K/N; stage PYTHONHOME and the generated tables for each.
  • Binder: walk the fork's artefacts (the binder is pinned to upstream Compose today; the fork keeps the public API, so the walk must produce the same bindings; guard with the stub diff in pythonx-compose Binder: public describe_member(kotlin_type_name, member_name) for resolvers #54).
  • Desktop Kotlin/Native target for the interpreter (macOS, Linux, mingwX64) if the K/N path needs it.
  • sample/: one build per path; the notebook E2E (python-multiplatform-compose/fixtures/notebook-e2e) runs on each.

Requirements already given to the fork side (darkpyonix leader, 2026-10-04)

The upcall table approach stays; no runtime reflection.

When

After torchnative, in python-multiplatform's turn, and after the fork finishes both paths.

Done when

The same pythonx-compose app runs unchanged on upstream Compose, extended GraalVM and extended K/N desktop builds, each with the notebook E2E passing in CI.

Activity

  1. b-re-w commented on Oct 4, 2026

    @b-re-w
    MemberAuthor

    Fork entry points (ComposeRust designer, 2026-10-04): module extended/window/common (fork PR #34, extended 8c7d11215a5), package org.thisisthepy.compose.window, targets jvm, macosArm64, linuxX64, linuxArm64, Kotlin stdlib only. Platform layers native/macos, native/linux, graalvm/macos, graalvm/linux, windows-shared implement WindowPlatform (open, pump, measure, requestFrame, present, systemTheme, setTitle, setMinimumSize, setVisibility, clipboard, setImeSpot, showContextMenu, close) with WindowListener callbacks; GraalVM layers call C via @cfunction and come back through a reflection-free table. Upstream public API is guarded by fork PR #36 (extended-public-api.yml). Embedder hooks in androidx.compose.ui.internal (fork #19) need #192.

  2. added 2 commits that reference this issue on Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions