Hi Jetbrains, does this project aim to port Compos...
# compose-desktop
u
Hi Jetbrains, does this project aim to port Compose Desktop to Kotlin Native 🤩 ? https://github.com/JetBrains/kotlin-desktop-toolkit
👀 5
k
It serves a different purpose. This library provides Kotlin API to interact with OS. Consider it as a replacement for AWT in Kotlin/JVM world. It is still work in progress, and right now it is limited to JVM. Thus, the answer to the original question is no.
❤️ 11
u
@kropp Thank you very much for the reply, but I’m still a bit disappointed.😔
g
@אליהו הדס just curious, why do you want Compose on Kotlin Native?
u
@gildor There are many advantages to using a JVM, but also some drawbacks — in particular, the somewhat long startup time, the access to native APIs which is handled much better on Kotlin/Native, and the overlay of native elements like on iOS, which I would like to see in Compose.
👍 3
g
I mean, many of those are solvable though
don't get me wrong, for extensive Native Api interop native is better, but probably you want to keep it separated from compose anyway
u
Yes, everything can be solved, but compare the complexity of implementing my video player in a JVM versus on Android or iOS. https://github.com/kdroidFilter/ComposeMediaPlayer
Yes, on iOS, Compose already uses Kotlin Native and it works really really well.
g
Yep
I just was curious what kind of issues it creates to use more stable and flexible JVM on desktop
u
Look also, I’ve developed an experimental TrayApp API, but the problem with a JVM is that it uses too much RAM, in my opinion, for an app that runs constantly on the machine. https://github.com/kdroidFilter/ComposeNativeTray?tab=readme-ov-file#-trayapp-experimental
☝️ 1
t
Multiplatform support would be great. I'm already using Kotlin/Native on macOS and GraalVM on Windows for my Hue Essentials app. For both platforms the startup time is better, and with GraalVM on Windows cpu/memory usage is also significantly lower.
u
@Thomas Can you share an example of a compose configuration with graalvm? I'm very interested.
t
It is quite complicated to get working, and unfortunately my project is not open source and I do not have it in a demo currently. But what I did is create an additional gradle module targeting kotlin jvm, which contains all of the GraalVM configurations. It is a lot, like a few hundred lines, to get it working correctly with awt, as it is not officially supported. Many flags need to be passed to graalvm. In addition, you need to create ui tests which go through the app which generates GraalVM configuration. Mostly for reflection. I had to add a lot of tests with internal compose code to test all code paths, even things like mouse or keyboard input, copy to clipboard, different render apis, and every awt/swing api you use, need to be run in tests or they crash at runtime.
The improvements are definitely noticeable, but with how much work it is to get it running correctly, I'm not sure it's worth it for every app. I had users complain about startup time with JVM so I had to use graalvm, and it was worth the extra work for sure.
u
yes well it's not that simple :)
g
JVM is that it uses too much RAM, in my opinion, for an app that runs constantly on the machine
@אליהו הדס have you tried to experiment with Graal Native Image?
u
@gildor I couldn't get my app to work with GraalVM.
g
This probably could be a good candidate to report, I really looking into Native Image builds for Kotlin desktop apps
💯 1
u
maybe it will be simpler with the new kotlin desktop toolkit, because the main problem with graalvm is awt from what I understand
@kropp am I wrong?
k
Kotlin desktop toolkit may enable a different approach for Compose Multiplatform, but it is too early to say. Anyway, we are in contact with the team behind this library.
Regarding GraalVM I don't have enough experience