How could I implement my own `*.compose` library c...

# compose-desktop

[ventura]

How could I implement my own *.compose library calling native components in C/C++?

[ventura]

I was digging into Jetpack Compose trying to understand how the native classes are implemented. But the components inherit from AWT classes, so I wonder if (or how) it is possible

[olonho]

One could use JNI

[jim]

Or KotlinNative C Interop (https://kotlinlang.org/docs/reference/native/c_interop.html), right?

[ventura]

@jim it is less about C/C++ interop and more about implement the Compose classes with native C/C++ components

[ventura]

For example, if I wish to implement a wrapper to native Qt5

[jim]

So you are looking for something like AndroidView except for Qt5?

[ventura]

touché

[ventura]

@jim the hierarchy is

androidx.compose.desktop.AppFrame
    androidx.compose.desktop.AppWindow
        androidx.compose.desktop.Window

and AppFrame has

abstract class AppFrame {
    abstract val window: ComposeWindow
    internal var menuBar: MenuBar? = null
}

[ventura]

ComposeWindow and MenuBar are also androidx classes that internally use java.awt and javax.swing

[jim]

Yeah, there always needs to be some sort of entry point into Compose code. We implemented Swing, but we would be very open to community contributions that add support for other host ui toolkits.

[jim]

You may also want to look at SwingPanel, which is very much still a work in progress.

[ventura]

@jim Well, seems to be possible (a ugly hack, but possible). I will try to do a tutorial 😉

[jim]

In addition to a tutorial, feel free to propose any changes that might make it a less-ugly-hack or which add Qt5 support to compose desktop. As I mentioned, it wouldn't be a focus for us, but we're happy to take contributions. Readme is here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/README.md and we're always here in the slack channel to answer any questions.

[ventura]

@jim I shall start by studying this Swift UI tutorial. As soon as I finish a demo, you will be the first to know. Thank you for your help 😉

[Kirill Grouchnikov]

Long time ago Sun switched the implementation of "system" look-and-feel on Windows to use native painting and animation APIs. It wasn't a "real" Windows button instead of a Swing JButton, but was supposed to be the same calls to paint and animate it. It fell straight into the uncanny valley - it was 95% there, but the last 5% was and still is really noticeable.