https://kotlinlang.org logo
Join Slack
Powered by
So when are we going to get compose for mingwx64 t...
# compose-desktop
j
So when are we going to get compose for mingwx64 target? I want to make desktop applications without having to rely on java or graalvm to make windows applications. From what I gather the constraints to solve this is no longer there?
➕ 5
a
+1. would love this to happen
a
How are the constraints no longer there? Compose for Desktop is currently built on top of Java/AWT/Swing.
j
In the same way that mac and linux target exists, and that msys2 has skia bindings available, so in the event of https://github.com/JetBrains/skia-pack needing update, the bindings already exist?
a
The targets exist, but they don’t really work for anything serious.
j
There is no time like the present! For me personally, take it for what you want, is the last reason for why not to stick with Kotlin entirely. Compose is an awesome framework and I'd love to use it to build native applications. It sucks hard that I can not do serious non depdendency ridden desktop applications. I don't want to use Rust for this. I want to use Kotlin Native. Take this in the best way possible, we love Kotlin and we want to use it more. Currently I am either forced to use tacky GTK kotlin multiplatform libraries, create own bindings for nuklear or clay etc etc. That is not the issue, that issue is that I want to use compose because no matter what I do, compose is just that good.
a
I would also love to see native Compose for Desktop, but the state of the code currently is such that there’s a lot of work to do to make that happen. Kotlin native is still slower than JVM, even.
j
There is that aspect, my two cents are, it can not be slower than javascript and electron. I think most are fine with that knowledge, as long as it can be iterated on and more importantly provide ways to give a base for optimization wherever that comes from (contributions or internal within jetbrains) Otherwise we will never see improvements.
m
@Joakim Forslund I do not understand which real benefits you expect from a truly native Compose desktop app in contrast to the currently available Java based desktop apps. I’d expect that a normal user would not even be able to tell the difference. I also see no justification for this if I consider the enormous effort this would make not only for Jetbrains but also for all library maintainers. In my opinion, there are far more important areas in which the limited resources should be invested.
j
So the reason that you dont understand it, is a reason for why it should not be made? Yeah, sorry not gonna bother answering that further
👎🏼 1
👎 3
m
That’s the problem with “free speech” that there are people who dare to express their opinions even if they are different from yours.
🤡 1
☝🏼 1
☝️ 2
➕ 1
j
One reason could be the start-up time of JVM-based desktop apps. Takes a while for it to show up, I'd imagine that'd be quicker with non-JVM-included build.
a
Start-up time is about 500ms on my M1 Ultra. It’s not fast, but it’s far from being a real concern for most apps I imagine.
(from clicking the icon until a window with some UI is visible)
j
500ms is nice. On my Ryzen 7-7700 it takes 3-4 seconds for the UI to show up. Splash screen helps a lot, as that pops up instantly. I wonder: if the JVM wasn't bundled with each app, would it be faster, because it could .. fork an existing JVM process, if any?
a
Not without something to specifically handle that. I’m surprised about the time. A simple singleWindowApplication { Text(“Hello”) } takes 3-4 seconds for you?
I don’t know whether Ryzen 7-7700 is fast or not. M1 Ultra is top of the line for macs, but about 3 years old now.
j
My main app: first start 3-4s Subsequent starts: ~1.5s Hello World app: first start 2s Subsequent starts: <1s I measure them installed, starting from start menu.
But in daily use, my main app usually takes the 3s to load. I always assumed it would be because of firing up the bundled JVM 👀
a
If subsequent starts are faster it’s probably because the data on the disk has been cached in memory. Native would only make that part faster if the binary itself was smaller.
Except for reading from disk, most of the startup time is classloading.
And we have a lot of classes, unfortunately. A pure AWT app starts in about half the time as a Compose app.
You can shave a bit of time by “preloading” classes. Let me find the ticket where I analyzed this.
👀 1
s
+1! Would love to see this for Linux as well.
As for the usefulness of a native version, there are a few things that come to mind: app size (if you wanna do any embedded Linux development, JVM is a no-go), but most importantly having direct access to system APIs.
Currently we are limited by whatever the JVM supports regarding windowing. It's the reason Compose apps are stuck with X11 on Linux, because JVM is still stuck on X11 (though Wayland progress is happening there, just... a bit late).
Then there's the multiple tickets about certain integrations being broken, such as dark mode support. It doesn't detect system dark theme changes, and to fix that you'll need to use some JNI bindings on each platform (wonky work), or use some extenal binding libraries. Dark mode is just one example, but there's all sorts of OS integrations that would require painstakingly writing JNI bindings (in C/C++/Rust). That alone defies the general vision for Kotlin as a language that naturally blends into its target environment.
@Alexander Maryanovsky What would it take to actually add support to a desktop target (e.g. Linux)? macOS already has an experimental Compose version with Kotlin/Native, would love to know if there's any documentation/article about that.
a
Dark mode changes are super easy to detect. Just query once a second.
Most native integrations can be done with JNA instead, which is much easier (also much slower, but that’s not important for most things).
Obviously that won’t work for embedded, but I’m not sure how suitable Compose is for embedded in general.
s
I'm aware of JNA, but it's a bit slow for some use-cases (e.g. reading touchpad driver input in real-time)
Compose itself is actually surprisingly efficient, it's probably going to run well on embedded (i don't have much to support my arguments tho 😅) I just found a talk by Jake Wharton where he implements Compose on K/N to run it... in a lightbulb controller 😅 (Compose\s sibling, Flutter, has first-class support for embedded as well)
j
@Skaldebane In general I would argue your latter part of the first paragraph is the more important one. We want to make native applications without an abstraction layer because there are applications we want to make that are native in nature. Things such as VSTi rendering and integration is one such example, not forcing extra dependencies on the user/developer in form of bindings or overhead is another. One step closer to the bare metal so we can start to improve performance for that. I've been through this cycle before. I've argued for Kotlin Coroutines getting androidNative support, i've argued for ktor getting mingxw64 support. They have after years finally been added. Jetbrain does a good job and either themselves or with external contributions to get to these points after some time. There is always someone that even with an explanation is not going to agree with the need. Well we are here to say there is a wish and want for this. I can't convince everyone why this is a good idea, because not everyone sees things from the same vantage point.
s
I agree with your points, but I'm sure they're not refusing our proposals. They're just suggesting ways to deal with things at the moment. If someone actually contributes such efforts, or Jetbrains themselves find the time, resources, and motive for it, I'm sure they won't have much against it!
It'd be better if we keep the conversation about the tech, without judging people's motives.
j
People have been trying to make this happen https://github.com/JetBrains/skia-pack/pull/20 and https://github.com/JetBrains/skiko/pull/574 but the poor dude has been left hanging for years without a single response.
s
I agree with @Michael Paus in that there are definitely more important things now than adding more targets. It's a big task, and the maintenance burden that comes with that will be ongoing. JVM does a lot of stuff for us, that will have to be re-implemented and maintained once you throw it away. The cool thing is that everything is open-source, so you can try taking a jab at it for your use-cases (though I'd recommend against that if you want to do anything serious with it, it's going to take a lot of time, effort, and research to get things up and running).
j
There are always bigger fish to catch, but native desktop is a legit business value thing to support. There is a big pull back from users that are simply not willing to install JVM be it for domain security reasons or that they don't want extra dependencies. But yeah, there are a lot of things to handle/coordinate so from that point you are correct
a
The lightbulb thing is cool, but it’s not Compose UI, obviously. The bulk of the work to support that would be in integrating with system APIs, and with a lightbulb there aren’t many.
s
You can consult this talk by Jake Wharton to get an idea of the sheer amount of work to get it working... for a single-use case. For proper desktop implementation you'd need windowing, handling input, intergrating with APIs, etc...

https://www.youtube.com/watch?v=D0P5Lb-2uCY▾

a
Users typically have no idea they’re installing a JVM. This isn’t the olden days when we asked users to install Java and double-click a jar.
➕ 2
s
@Alexander Maryanovsky Ah yeah, that's why I was asking about the parts that are required to actually get a proper implementation working, from windowing to input etc...
a
(Sorry, light switch; not bulb)
j
Users might not always be in controll over what can be installed either. Domain policies at companies simply does not allow JVM to be installed for a lot of companies because of the inherent security risks. At any case, we are getting down to minutia. If nothing else, I am one of those weird people that want and have a need for this. I understand we are not there yet, that it is not on the roadmap, but I very much would like to use compose multiplatform for this. Once again, I am reaching out because of my love for compose multiplatform.
s
We all do! I love Compose so much I'd decorate my house with it if possible (are we there yet? android xr? lol) But yeah, great things take time (and effort).
a
Not allowing a JVM to be installed for a specific app is silly. There’s exactly zero additional security risk.
💯 1
j
Is this what I am supposted to tell the companies that has the no java security policy rule as well?
a
You could explain why it’s silly…
j
Thanks for your time @Alexander Maryanovsky I appricate you took time to look at the message at any case
s
You could also use GraalVM if you definitely don't want the JVM Otherwise it's silly; you browser is doing the same thing all the time.
If the ban is some sort of Policy installed into Windows, you'd normally bundle the JDK with the Compose app, so that won't be an issue (as far as I'm aware). Nevertheless, the actual solution is to simply remove such a ban, because there's no instance in which JVM is more dangerous than native code (it's always the opposite :p)
➕ 1
To keep this conversation in-scope: we all want K/N Compose. There's many good reasons for it (embedded, perf, OS integration, etc...), but this is not one of them :/
m
And when you install a Compose desktop app where the JRE is bundled you technically do not even install a full JVM. Its just a subset of what is needed for your app. That’s what jlink is used internally for. In addition to that ProGuard is used to further shrink your installment. If a company forbids that, they’d also have to forbid things like Electron for example.
➕ 1
j
Yep and they do. And this is exactly why i do not want to enter into a vantage point understanding discussion. There are quite a few of variables in play here, I am not asking for them to be understood. I also would like for this conversation to stay on scope for the intended purpose as @Skaldebane refers to
m
It would be easier to use GraalVM Native Image to improve startup time
j
@mikehearn any starting point for that? I found https://github.com/esp-er/compose-graal-hello but it's 2 years old, not sure how much relevant stuff changed
m
That's a good starting point, yes. I mean, compared to the sort of work being talked about in this thread, updating that and improving it would be a lot easier. When that was done for JavaFX startup time became as fast as a native C++ Win32 app, so really fast.
Memory usage improved a lot too.
👀 1
It's a developer usability/experience issue, primarily. That's the hard part. Making sure everything works smoothly out of the box. Most devs and users don't care about startup time that much compared to features, so the moment it takes some time investment, it gets hard.
m
I tried that route already some time ago but it still had issues. AWT isn’t fully supported by GraalVM/native-image. See, e.g., here: https://github.com/oracle/graal/issues/4124 Using Liberica looked promissing but it had issues too. But if there would be enough interest in this, it should indeed be much easier to get that working than introducing new native platforms to compose.
s
There's also JWM: https://github.com/HumbleUI/JWM Extremely promising modern windowing toolkit for Java, sponsored by Jetbrains. Its development was going well for years, but the last commit was... 5 months ago. Unsure what happened there, will open an issue asking about the project's status.
Though their main project HumbleUI (a Clojure UI framework) is built on top of this and is still active. https://github.com/HumbleUI/HumbleUI
There was even an experiment to get Compose working on JWM that the author embraced https://github.com/smallshen/JWM-Compose/
m
There are forks of GraalVM that improve desktop support
m
@mikehearn Could you point me to one which really works with Compose? Only support for AWT is not enough. Last time I tried (and talked about it with the people from Liberica) there were also strange things going on how Compose loads shared libraries which somehow conflicts with GraalVM/native-image. I finally gave up on this because there doesn’t seem to be enough interest on any side to fix these issues.
m
I was thinking of Liberica. I haven't worked on getting compose to run natively myself.
It does need someone with the right skills to just make it their mission to solve this. Mostly people seem fine with Hotspot though
👌 1
20 Views
Open in Slack
PreviousNext
Powered by