is there a possibility or future to use Qt with ko...

# kotlin-native

[sreich]

is there a possibility or future to use Qt with kotlin-native? Is that something that would require a big "bindings" project, or should it kind of just work? I know there's a lot of complexity with Qt

[Tijl]

Qt is C++ and maintains no official C API so it will not “just work”.

There’s plenty of binding projects to other languages, so of course it can be done, but it’s not a small job.

[sreich]

so other language interoperability is contingent upon having a C API? why is that?

[mbonnin]

C++ is order of magnitudes more complex than C

[Tijl]

nothing is contingent on one thing, but Kotlin-native has cinterop which makes it really easy (“kind of just works”) to interop with C style APIs.

I’m not aware of any other interop for Kotlin/Native that “kind of just works” so then you’ll have to be the one to make it work.

There’s probably other efforts that do something like that for interop with other languages already though (my guess would be to check Rust or Go bindings), but QT is a massive framework with very specific constructs that are not straightforwardly mapped to other languages. It’s going to be a “big bindings project” regardless.

There’s some half (quarter? one millionth?) finished C++ interop in the kotlin native source code, but it for sure is not going to work with QT.

[sreich]

@Tijl thank you, that was a nicely detailed explanation like i was looking for. cheers

[ephemient]

C++ interop is challenging for every language, not just Kotlin. Rust's bindgen creates a C layer and only supports a subset of C++. SIP and Shiboken both create a C/libpython layer and require specially-formatted inputs and extra manually written bindings. SWIG also only handles a subset of C++ itself and requires manually written bindings for the rest.

[ephemient]

basically, the C ABI is relatively simple (mostly consisting of calling convention and structure layout), and while there is some complexity in parsing C declarations, it pales in comparison to C++ where the ABI is highly complex, highly platform-dependent, not stable across versions, not even necessarily stable across compiler vendors, and the declarations are near impossible to parse completely with anything short of a real C++ compiler

[ephemient]

if you're focused on Qt in particular, perhaps you could mangle SIP or Shiboken (used by PyQt and PySide respectively) to produce Kotlin bindings instead of Python bindings. they've already done most of the hard work of figuring out how to parse the Qt library's definitions from source and documentation and extra annotations, and wrapping the C++ calls into something usable by other languages

[ephemient]

as https://dlang.org/spec/cpp_interface.html says,

Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable. Other languages looking to hook up to C++ face the same problem

I don't know if Kotlin/Native will ever extend cinterop to C++, but at best it'll be a subset similar to D

[Tijl]

as an example of the effort required even if you have a proper C API (GTK in this case), to see the effort to make a Kotlin style DSL for it you can check https://gitlab.com/gtk-kt/gtk-kt

I’d argue it’s still a “big binding project”. the author hangs on this slack too AFAIK.