For Compose for Desktop, allow to use Swing Components instead of rendering via skia (composable Swing)

[SerVB]

I propose supporting a way that currently implemented in Compose for Web: it uses native DOM elements, not a single canvas. A similar feature would be handy for Compose for Desktop: creating Swing apps but in Kotlin and with the use of composable functions.

Other pros would be that it will support Swing LaFs as well as other standard Swing things like Accessibility.
The obvious con is that it can be not as performant as rendering to a single canvas. And also of course it will require some additional work in Compose for Desktop – it doesn't sound like an easy task.

Related to #1521?

[akurasov]

Compose supports a11y at the same level as Swing does. Pure Swing LaF is not that popular and customizing LF in Compose is easier than in Swing. As such I don't see much benefits in it, but the costs are huge.

[SerVB]

Swing LaFs are different, for example, I like native LaF and IntelliJ LaF. And would be cool to have an easy option to create Compose apps not bound to Material Design. Maybe it's a separate issue to support different LaFs.

Regarding a11y, I'm actually not an expert, maybe Compose and Swing are already comparable and can work together at the same time: I haven't checked.

What I mean is that using native Swing components has the benefit that many concepts will be inherited from Swing. Would be easier for those who already know Swing. And also to rewrite the app incrementally.

Of course I agree that it can be low demand for this feature.

[akurasov]

Maybe it's a separate issue to support different LaFs.

This is one of our focuses now.

And also to rewrite the app incrementally.

It is already here. There is two-way interop between Swing and Compose. You can easily rewrite only part of your app in Compose, keeping the rest in Swing.

[SerVB]

This is one of our focuses now.

Cool!

It is already here. There is two-way interop between Swing and Compose. You can easily rewrite only part of your app in Compose, keeping the rest in Swing.

I know that interop and partial rewriting are here but as I've said I just mean composable Swing could "be easier". Now, we need to rewrite a piece of UI from Swing to quite different Compose. But it would be easier to firstly rewrite from Swing to composable Swing, and only then, if needed, to native Compose components.

[SerVB]

Still, composable Swing doesn't look to me as a crazy idea: we already have composable DOM as the only available option in Compose for Web, and maybe a single canvas will come to Compose for Web later, but composable DOM will be still useful because it reuses already known concepts for plain Web.

And the same for composable Swing.

[akurasov]

It is not crazy) Just efforts/value ratio is much less than many other features have.

Also there is significant difference between DOM and Swing. Dom(HTML) is a declarative language, while Swing-java is definitely not.

[kirill-grouchnikov]

Swing is a dead end. It has been effectively abandoned in 2008 in favor of JavaFX, and there hasn't been any major development in that area since then. It has evolved a bit to support hi-dpi displays, and maybe Metal-based rendering pipeline on macOS, but there has been no real app-facing development in the last 13 years.

Sure, Swing components come with built-in support for multiple look-and-feels, including the system ones. If you look close enough though, there are a lot of broken edges on Windows and macOS where the "native" look-and-feel is showing the signs of these 13 years of stagnation.

And then, of course, you have a widget API surface that has not kept up with the times. Whatever the APIs are on JButton or JSlider, that's it. There's not going to be anything new in there, like support for split buttons, popup buttons or multi-selector sliders (like a slider with two knobs to select a range). There's not going to be a date picker, a time picker, a pivot table, ... - and third-part component ecosystem that was once there, is effectively dead at this point. And those components that are still alive, in a manner of speaking, certainly do not support that variety of look-and-feels at a decent enough level.

The TL;DR version of it is simple. You don't really want to tie the future of Compose to the legacy shackles of Swing which has been frozen in time at what it was back in 2008.

[zeruth]

Swing is a dead end.

Surely it being a part of compose already should tell you otherwise. Swing is fantastic. It will live on for a long time.

[akurasov]

This discussion seem to be converting to flame. I close it.

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.