Experimental example application without AWT implementation

[igordmn]

Desktop target of Compose Multiplatform uses AWT/Swing under the hood. It adds many advantages, but also adds many issues.

Investigate:

• if it feasible to replace AWT by something else
• if it feasible to support GraalVM, or even Kotlin Native for desktop OS'es

We can:

1. Write a sample application with not simple UI on stable Compose Multiplatform
2. Try to gradually get rid of AWT dependencies in Compose/Skiko. Just leave stubs at the moment. We are only investigating.
3. Implement support for GraalVM
4. [optional] Implement support for Kotlin Native (we already have some prototypes for macOS)
5. Compare all implementations in terms of performance (RAM, the startup time, FPS)
6. Make a list of features that we need to reimplement when we get rid of AWT.

Note, that AWT/Swing implementation will still be needed for Swing interop (needed for IDEA interop).

P.S. We have one very simple example without AWT here: https://github.com/JetBrains/compose-jb/tree/master/experimental/lwjgl-integration

[sureshg]

Thought of sharing this here as compose-jb team is exploring the AOT compilation. Dynamic linking of AWT libraries are now available on Windows and Linux GraalVM native images (changes are merged last week) - oracle/graal@f375678 . I think they are now working on the mac os support and is tracked as part of this issue - oracle/graal#4921

[mipastgt]

It would be interesting to see whether this issue JetBrains/skiko#580 which I originaly reported to bellsoft bell-sw/LibericaNIK#14 here will be fixed by these changes once they land on the mac.

[wakaztahir]

Any updates ? I'd really prefer Kotlin Native since that'll bring direct native support and sometimes just interacting with OS gets hard in JVM, e.g opening a folder selection dialog

[dima-avdeev-jb]

Any updates ?

It is very interesting experimental research.
But, for now we are pausing it. Because we want to provide another features and bug fixes.
I hope we will continue it later!
Stay tunned!

[jershell]

When it will to continue i think we can check skiko+(GLFW or SDL) as backend for support native target.
some points

• provide input methods and base window api
• crossplatform
• SDL/GLFW is written in C
• SDL/GLFW is hardware accelerated

[Laxystem]

Is Kotlin/WASI support also planned/experimented with?

[dima-avdeev-jb]

@Laxystem Do you mean Compose with Wasm?
Yes, Compose Wasm is experimental now.
Here we have one very early experimental example: https://github.com/Kotlin/kotlin-wasm-examples/tree/main/compose-imageviewer#compose-multiplatform-for-web
Latter we will migrate all our examples to WASM too

[Laxystem]

@Laxystem Do you mean Compose with Wasm? Yes, Compose Wasm is experimental now. Here we have one very early experimental example: https://github.com/Kotlin/kotlin-wasm-examples/tree/main/compose-imageviewer#compose-multiplatform-for-web Latter we will migrate all our examples to WASM too

I mean, Kotlin supports two Wasm targets, Kotlin/WasmJS (for the web) and Kotlin/WasmWASI (for everything else, via the WASI libraries).

Afaik Compose/Wasm only compiles to Kotlin/WasmJS. Is compose also experimenting with supporting Kotlin/WasmWASI?

[jershell]

@Laxystem Do you mean Compose with Wasm? Yes, Compose Wasm is experimental now. Here we have one very early experimental example: https://github.com/Kotlin/kotlin-wasm-examples/tree/main/compose-imageviewer#compose-multiplatform-for-web Latter we will migrate all our examples to WASM too

I mean, Kotlin supports two Wasm targets, Kotlin/WasmJS (for the web) and Kotlin/WasmWASI (for everything else, via the WASI libraries).

Afaik Compose/Wasm only compiles to Kotlin/WasmJS. Is compose also experimenting with supporting
Kotlin/WasmWASI?

I think at the moment there is no way to get the user interface of the application. This is not part of wasi. Depending on the difference in the runtime implementation, it may work with the imported functions.

WebAssembly/WASI#53

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.