Decompose core availability for Kotlin/Native targets

[LandryNorris]

The only actual found in jvmMain and darwinMain is assertMainThread. Because of this, it should be possible to port the core to other Kotlin/Native targets besides macOS/iOS. On Linux, this could be implemented with a tid/pid check. This would allow ComponentContext to be used in Kotlin/Native projects.

[arkivanov]

What K/N targets are you interested in? What's your use cases?

The main thread thread assertions are likely to go away in scope of #343

But I would prefer to avoid supporting all possible targets without demand.

[LandryNorris]

My main use case is for Linux. Because Kotlin/Native supports GTK, I'd like to port some of my desktop projects to Kotlin/Native. Additionally, for a work project, some of the devs requested a desktop port for testing to have access to better tooling than is available for mobile. Since the project is Kotlin/Native (needs access to some C libraries, so no JVM), I wanted to add a linux target, and write a quick UI using SDL, but since it uses decompose, I can't easily add Linux support.

[arkivanov]

Is it just linuxX64 that you would like to have?

[arkivanov]

Also, how are you planning to integrate GTK with Decompose? Specifically, how are you going to switch views on navigation?

[LandryNorris]

For my use-case, linuxX64 would be sufficient, but others may have different use-cases. I haven't quite figured how I'll switch views on navigation, but I worked on one project that required UIKit on iOS, so I'll likely implement it similar to how I implemented the UIKit version, where I issue a navigation event when the navigation state changes.

[LandryNorris]

Out of curiosity, what is the main blocker for more platforms? If testing is the main concern, linuxX64 is the only tier 1 target not currently supported from first glance. You could follow (the tiered support system)[https://kotlinlang.org/docs/native-target-support.html#tier-1] JetBrains set up, which would allow more targets to be supported without testing that they run properly in CI.

[arkivanov]

There are no known blockers, I just don't want to blindly add support for every target without any demand or use cases. Because every target requires resources for maintenance, and also CI resources for builds, tests and publications. So I'm trying to investigate each request wisely.

Decompose is primarily designed for declarative UI frameworks. Of course, it can also be used with classic imperative UI frameworks, but efficient UI updates (e.g. diffing) are pretty tricky to implement. This is what I'm trying to investigate before adding support.

[LandryNorris]

That's fair. When I work with Imperative frameworks, I typically split the state more that usual, and have on*StateChanged methods that compare each field to the last value, performing an update when a given field has changed. Often, I'll have a multiplatform project that supports declarative UI on some platforms, and imperative on others. Hopefully once Compose for iOS and macos is stable, they'll work on adding more support for native compose, but until then, I guess GTK it is.

[arkivanov]

Just checking, is there still an interest in supporting linuxX64?

[arkivanov]

Closing this for now.