Hey, is there any roadmap of what is planned for the future with compose-dekstop?

There is no specific roadmap at the moment, as we are eager to listen to feedback. Are you looking for something specific?

@alexey.tsvetkov I’d love to see a roadmap of planned features. It feels like there are a few pieces missing around shipping a production application, and it’s helpful to know what’s coming so that people don’t waste time building it, or figuring it out for themselves. i.e. I’d love to see an auto-update feature where we can compile an update bundle alongside our DMG / MSI. • That way people don’t have to download the entire JVM for every release. • More importantly the user doesn’t have to drag files around or do anything to update.

Well, auto update shouldn't be a feature of an UI framework, I suppose?

CfD is already more than just an UI framework. And this feature seems to be important. Another question is - how easy it is implement it…

@mcpiroman Given that it builds and packages the framework for us, it’s a good fit to support this in the gradle plugin imo. @Alexander Kurasov[JB] It’s lots of simple problems to solve that are complex when combined together I think. Lots of smaller questions come up: 1. How does the app hook in and provide its own custom update UI? 2. How do you do this on windows? 3. How do you allow not only for the classes to be updated, but the JVM as well? The solution I’ve played around with in my head is to download all the changed files from the previous version, and then downloading a small Kotlin Native executable for the specific platform, and then running that native executable, killing the current process, having the native executable swap out all the files, and then restarting the application. It’s also theoretically possible though to live update the application without even killing the process if you are only updating classes. I’ve tried this though, and it’s much more complicated than I’d hoped.

@spierce7 an auto-update is also the thing I'm looking for my project. A have a research-ticket about looking at https://github.com/update4j/update4j . Haven't seen yet, but may be the thing we need.

@rcd27 Perhaps my discussion with the library author will be of help to you - https://github.com/update4j/update4j/issues/149

@spierce7 thanks!

@Alexander Kurasov[JB] apart from general curiosity about the direction of things, I'm wondering if there will be either better support for opengl/vulkan (I've seen some experimental code with lwjgl 🎉) or for showing millions of objects. I'm interested in creating a tool for particles simulations at the moment, the problem is that I saw some tests where the jetpack could barely show 100k objects, so if the future isn't bright in this matter I can always choose imgui

@Michał Kalinowski Jetpack works on Android. You can try to build PoC for you app on Compose Multiplatform. Though I can hardly imagine, how you will fit 1M particles even on 4K screen….

Yeah, but Android has good Vulkan and OpenGL ES support, that seems enough to get around the restrictions 🙂. And when it comes to numbers, Bifrost for example in Maya can show up 50 million particles without a problem.

not sure what do you mean by “better support for OpenGL”, ability to do direct OpenGL calls to Compose canvas?

@olonho Basically I'm talking about any way that I can plug into some view (can be canvas) so that custom renderer(opengl/vulkan/directx) can draw into it. Android has such a thing, compose doesn't. In simulations where there are millions of particles, you may need to show them as a whole, because particles can be semi-transparent and pass through each other. No sorting is involved since often it is easier to display millions of objects by instancing than to sort them.