https://kotlinlang.org logo
Join Slack
Powered by
are there plans for native linux support as there ...
# compose-desktop
j
are there plans for native linux support as there is for native macos?
đź‘€ 11
r
Is there native support for macos? I thought only via JVM
a
Really hoping for native support on all 3 OSs personally
m
@Radoslaw Juszczyk The https://github.com/JetBrains/compose-jb/tree/master/experimental/examples/chat-mpp/src example still has the macos target. It was dropped though from the falling-balls-mpp example. I tried it and it worked (sort of) but had some problems which the JVM variant did not have so I really never saw the need to further use it.
j
I'm having trouble using the JVM on a smaller embedded device running Linux and being able to just target native Linux would probably help significantly (although not totally, I expect)
Plus the JVM is huge (50MiB jlink jre) for small devices
i
We didn't plan adding support for native Linux/Windows in the near future. Stabilization of macOS target also isn't in our near plans. It may be good if we support them someday, but It is a lot of work.
j
Would be nice to see longer term if possible. Flutter works really well on these devices, but it's unappealing to me in every other aspect.
m
In theory it would also be possible to just compile your code via GraalVM/Native-image but this currently fails due to a strange Skia library handling.
j
Haha yes, true, but it's a bit of a roundabout way to get where I want to go.
m
What do you mean by “roundabout way to get where I want to go” and what are your main limiting factors? (RAM, DISK, …)
j
Kotlin supports compilation to native directly (well, though llvm). Skia is already a native library. Going through a JVM target only to go to a native image means I still retain a bunch of JVM-specific behavior and indirection that I don't need or want.
l
The Compose Native codebase appears to be using pure skiko as much as possible. I’m sure if someone were to contribute Linux support to skiko (outside of the JVM bindings they already have for JVM skiko), it wouldn’t be as difficult to port Compose to Linux.
j
Yeah the difficult part of the port isn't Compose UI's interaction with skiko but more the APIs surrounding creation of windows for applications and dialogs, interfacing with the system for things like density, fonts, etc., and probably more I don't even know of.
l
That’s fair. It seems like the focus is primarily on iOS for Compose Native. It looks like macos is also added since it uses UIKit as well.
j
MacOS uses AppKit not UIKit, strictly speaking, so it's similar but not entirely the same. UIKit on MacOS requires using Catalyst.
Input handling is probably a huge part of porting that I left out. And propagating out accessibility information.
e
Would it be possible (or desirable) to build out native support on top of qt, similarly to what's done with swing on the JVM? Asking with very little more than zero experience with qt
m
What's the parts of the JVM that get in the way? A graalvm native image can be pretty minimal - you get the GC and Java memory model but Kotlin uses that anyway. Reflection, JMX, etc, all that stuff can be turned off and the tool deletes unused code. The problem is mostly binary size because of the heap snapshot, and lower peak perf than hotspot unless you pay for EE, but memory usage is usually 10x lower. There's a company that specializes in using native image for embedded devices, iirc.
j
if i'm targeting native it's simply an indirection i don't feel is necessary to take
i'm not using an existing corpus of Java or Kotlin/JVM code, i'm not using Java-only libraries, i don't need Swing. the JVM provides me nothing for what I'm trying to do. that's all.
m
Right. A graal native image is sort of a half way house. You get a GC, whatever native code your app needs and a minimal runtime (threading, file io etc). Kotlin/Native has to provide the same. It's not like the regular JVM where there's tons of extra features. Beyond that the bloat will come from Swing. Most of it would be erased by the dead code analysis (e.g. the widgets), but probably there's still some overhead left. A port of Kotlin/Native to JWM would fix that. Otherwise, Kotlin/Native is pretty similar conceptually to a native image, just using Graal instead of LLVM. The most JVM-y bits mostly boil away.
j
It seems like it should be a minor crime to take a language that can target llvm and native libraries directly and instead target the JVM and those native libs through JNI only to then run an elaborate tool to synthesize a truly native binary from it.
m
It definitely feels weird, but K/N goes from Kotlin -> LLVM bitcode -> native code. Graal path goes Kotlin -> JVM bytecode -> native code. It's conceptually the same, so which is better comes down to how much efficiency you lose (if any), compatibility, IL features, GC quality
l
Keep in mind that K/N is relatively new, and the ecosystem isn’t quite as large as the JVM. This could change over time.
j
I'm trying to make it bigger!
Anyway I take your point, but a jlinked JRE is small enough. And jlink can run on jmods from another architecture meaning you can effectively cross compile if you get the right skiko
My problem now seems to be skiko for Linux assumes X11 and GL but my device is closer to Android and only has EGL so I'm going to try to compile my own
Plus I want to use R8 not proguard
m
Just in case someone is going to further investigate the possibility to create a native image of a JVM compose application via GraalVM here are the links to the issues which currently prohibit this. I tried it on a Mac (but the result on Linux is supposed to be the same). Because GraalVM/Native-Image does not yet fully support AWT (which is needed for Compose) I used the NIK distribution from Bellsoft which has this support for Mac. https://github.com/bell-sw/Liberica/issues/94 https://github.com/JetBrains/skiko/issues/580
42 Views
Open in Slack
PreviousNext
Powered by