https://kotlinlang.org logo
Join Slack
Powered by
I've been wondering for a long time, why does Comp...
# compose-desktop
s
I've been wondering for a long time, why does Compose Desktop use AWT/Swing over GLFW or another windowing toolkit? I got frustrated at the X-only AWT and just switched my app over from the stock 
application {}
host to a custom 
glfwApplication
host for proper Wayland support and wow it's so nice, resize is fluid, scaling on wayland works properly. It's not even hard to do (though there's a lot of little details to wire up for parity, like menus, input, clipboard, etc), will prob extract this code into a proper library tonight. As a bonus, controlling the host means I control the gpu context, and can expose a hook for other gpu-accelerated renderers to draw in a shared texture and sample that into a Canvas, getting a super clean implementation of something like this
k
the heuristic could be part of the standard library, why dont you push it upstream to start a discussion there linux is either x or wayland, many use hyprland etc.. one could modulate use of this only on wayland, for ideal performance and portability
s
it'd be a pretty major component to swap out, but I wouldn't mind pushing it upstream if jetbrains would like it the only reasons to avoid it I can think of: โ€ข binary size: using AWT built into Java is smaller than adding additional native libraries like GLFW โ€ข you lose SwingPanel (but SwingPanel is mostly unusable imo anyway) โ€ข it's not that hard to build outside the core, basically no downside to a third party library other than lagging behind jetbrains' release cycle a bit โ—ฆ (well, filling out the platform context feature matrix across platforms is a lot, but it's not particularly novel stuff) it's well worth it imo, opens up a ton of potential for modernizing compose desktop apps (beyond wayland, like proper touch input)
e
JetBrains is already invested in Swing/AWT (with various fixes and improvements in JBR)
but yeah there's a lot that might be better with a different windowing system, and you wouldn't be the only one looking into it
j
There's changes now in the last week or two that make this easier, for what it's worth.
e
s
"Progress Update as of Nov, 7 2023" damn lol hopefully it just reflects they stopped updating this issue rather than progress stalled
j
It's worth supporting as a possibility, but probably not as the first-party offering.
s
There's changes now in the last week or two that make this easier, for what it's worth.
say more?
It's worth supporting as a possibility, but probably not as the first-party offering.
fair enough, it mostly works just fine as a third party library. I just have to 
@OptIn
to 
InternalComposeUiApi
in a few places so am tightly coupled to a Compose version, which is reasonable
e
https://github.com/JetBrains/kotlin-desktop-toolkit
will later provide an OS integration layer for Compose for Desktop
j
s
kotlin-desktop-toolkit
ooh, nice
neat, I hit 4799 the hard way with some odd crashes, eventually figured it out and resolved it with a custom dispatcher looking into the GlobalSnapshotManager stuff; haven't needed to look at that yet and I'm unsure what "snapshot apply notifications" refers to
j
that's the mechanism by which Compose advances the global snapshot and allows state mutations to be observed
s
ahhh that snapshot
I'm not executing my compose scene in other threads so I haven't hit the snapshot manager issue. I guess I'll make that an explicit guard in my library for now, matching android's architecture, and dig in later Thanks for the links all!
s
Looking at the 2.0 branch of Nucleus, I think @ืืœื™ื”ื• ื”ื“ืก is trying to replace AWT with Tauri's tao
โค๏ธ 2
u
I've already replaced it in my production application with over 10k users, and all my users loved the touch support and the fast startup thanks to the native GraalVM image.
โค๏ธ 1
s
Just published https://github.com/sargunv/compose-glfw to maven Limitations: โ€ข single window for now โ€ข linux only for now (wayland and x11) โ€ข a few missing features (screen reader, native menus, tray, dialogs, file pickers, etc)
Will go build for macos and windows later; should be relatively straightforward ports (bootstrap metal and d3d, implement light/dark mode provider, rest is via glfw so reasonably cross platform)
^ And just pushed a new release with macOS and Linux support, native file pickers, multi window application composition, and some other improvements
m
@ืืœื™ื”ื• ื”ื“ืก Is that Tauri based windowing already part of Nucleus 2.0 and is it usable for testing?
u
@Michael Paus Yes, of course. The pre-releases are available on Maven Central. I personally use it in my app, which has more than 10k active users, and itโ€™s also a very large application.
For now, it has only been tested on Compose 1.10.3 because Jewel has not yet migrated to Compose 1.11.
m
But it can also be used independently of Jewel, right? So testing it on an application which already uses Compose 1.11 should work? Which platform do you think would have the most benefit from such a switch? To be honest, on my macBook M4 I do not really feel the pain but I heard that the situation is different on other platforms.
u
It uses Skikoโ€™s internal APIs, so itโ€™s possible that things changed between Compose 1.10 and 1.11. Because of that, I canโ€™t guarantee that it will still work as-is. More generally, Iโ€™m planning to migrate Nucleus to Jewel, since all of my desktop apps already use Jewel. The biggest gain is clearly on Windows. Around 50% of my users are still on Windows 10, often on fairly old machines, and Windows is notoriously sluggish when it comes to compilation and startup times. In practice, the difference is very noticeable: Iโ€™ve had quite a few users tell me that startup time went from roughly 20 seconds down to 1 second. On top of that, AWT was also fairly heavy to load, so no longer relying on it improves startup time even further. On Windows, it also brings native accessibility support, which is another significant benefit. Iโ€™d also estimate that around 15% of my users have touchscreen PCs, and theyโ€™ve really appreciated the native support for touch input and gestures. There are also major benefits on Linux, especially with native Wayland support and native accessibility support. On macOS, though, the difference is less noticeable for now, aside from better performance when resizing windows. That said, the Tao backend provides a 
NativeView
component that makes it possible to overlay a native view and then render Compose on top of it. Long term, I plan to use that for things like WebViews and video playback without relying on offscreen rendering. And in that case, the gains on macOS could become very significant as well.
thank you color 1
I also think the biggest advantage, and the part that required the most work on my end, is the almost transparent support for existing applications. A lot of Compose libraries, such as Compose Navigation, do not work well without AWT, and Nucleus handles that. I think the migration should be very straightforward.
For example, Jewel is also very tightly coupled to AWT. It wasnโ€™t easy to make it work on my side, but without that, it wouldnโ€™t really be worth it. To me, Jewel is one of the biggest advantages of Compose Desktop.
๐Ÿ™ 1
m
@ืืœื™ื”ื• ื”ื“ืก Thanks a lot. This raises a lot more questions but I do not want to conquer this thread.
s
(feel free to conquer this thread, I'm also interested ๐Ÿ˜€)
โค๏ธ 1
A lot of Compose libraries, such as Compose Navigation, do not work well without AWT
Curious what issues you encountered with compose navigation? I haven't done anything special for it, and my app seems to work just fine in my glfw host
k
it seems kotlin-desktop-tooling is already the large official jetbrains questchain that aims to replace AWT with kotlin idiomatic, modular, native backends like: .Compose UI โ†“ Stable Desktop Platform API โ†“ Backend chosen per platform/runtime: AWT / JBR Native macOS Native Windows Native X11 Native Wayland the table displayed in readme, in kotlin window mgmt (kotlin-desktop-toolkit) shows the remaining amount of work for optimisations. Your work could go there if its relevant perhaps
m
(Originally posted in wrong channel) OK, you asked for it. @ืืœื™ื”ื• ื”ื“ืก You mentioned Jewel. What makes Jewel so outstanding for you? I haven't used it yet but looking at it briefly I did not see anything so exciting for me? Can you elaborate on that a bit. Jewel also comes with its own style and components and I am wondering how easy it would be to style it with something else, e.g., compose unstyled, or would that just mean in the end to use two competing frameworks in the same application?
u
@Michael Paus So, I'm in the camp that believes a desktop application isn't a website, and it isn't a mobile app either โ€” it's its own thing, with its own patterns and its own use cases. A desktop app doesn't need to be responsive the way a website does, nor does it need to be sized for a fingertip. More often than not, it's a productivity tool: it displays a ton of content at once, it doesn't ask the user to navigate from screen to screen, it's built for getting work done. And that's exactly what Jewel was designed for. It gives you the components and patterns to build a real desktop app, not an Electron app written in Compose. Everything is built around mouse and keyboard usage: keyboard accessibility is wired in out of the box, and you get control over the smallest details, right down to scrollbar behavior. And that's the real point: no other multiplatform framework actually offers a UI designed for desktop. Which means if you go with them, you'll have to reimplement all those patterns yourself. The really good Electron apps do this, but most don't โ€” or not the way they should. Jewel gives you all of that out of the box: you don't really have to think about it, you just use it. In fact, Jewel can't be multiplatform by design, and it's not just a matter of components โ€” it simply wouldn't work on other platforms. It's real desktop, the way we like it โ€” it's 20 years of IntelliJ experience behind it. And despite all that, they managed to keep the API flexible. Maybe not as flexible as Compose Unstyled, which I also use with Compose Web, but more than enough for your app to have its own identity. That said, no โ€” you shouldn't mix the two frameworks: the rendering wouldn't be consistent. Better to pick one and stick with it.
thank you color 1
@seb What do you think?
I'll go out on a limb and say that if an app like Claude Code Desktop had been built with Jewel, it would have been gorgeous. As it stands today, it's awful โ€” it was built by web developers who don't know what a desktop app is and end up reinventing the wheel. OpenAI, with Codex on Mac, used SwiftUI, which was actually designed for desktop, and anyone can see the staggering difference in quality between the two apps. I think Jewel would deliver that same level of quality โ€” except it gives you a multiplatform application, unlike Apple, which caps you at macOS.
๐Ÿ‘ 1
s
Yeah pretty much our philosophy. We decided early on to focus on the best possible desktop experience rather than try a one size fits none approach that other libraries and frameworks have
Because we also support IntelliJ plugins, the AWT dependency is baked in. However I'd love to try out supporting KDT too eventually, as for standalone apps it's a lot nicer as I understand
I'm also doing a looong running experiment with a custom JBR renderer that uses Skia for everything โ€” Compose and Swing alike โ€” effectively eliminating a whole class of interop issues and performance penalties
๐Ÿ˜ฎ 2
I'll share more when I have more to share. It may pan out to not being worth it, but I think it'd be great to have. I then only need to convince JetBrains to adopt it in case lol
u
That would be so cool!
s
But yeah Jewel only targets the desktop as it implements a design system that is only aimed at the desktop. There isn't any other Compose theme/framework that properly targets desktop. Radiance is the other one, but I am personally not a fan of the XP-era visuals, even though engineering wise it's excellent. Compose Unstyled is the one that gets the closest after that and yet it's definitely not optimised for desktop โ€” by its nature.
u
radiance ? you mean aurora ?
I'm not a fan of the retro look either; I haven't tried it.
s
Sorry yeah radiance is the swing version if I'm not mistaken
192 Views
Open in Slack
PreviousNext
Powered by