GUI for Kotlin|Native

Native
1

Dear All,

I assume that there is a shortage of GUI tools for Kotlin|Native.
I’ve been advised that currently the only alternative is libui (GitHub - msink/kotlin-libui: Kotlin/Native interop to libui: a portable GUI library).
When I tried to use it, I noticed that it has virtually no documentation apart from autogenerated.
For me as a newbie to both Kotlin|Native and GUI it’s virtually impossible to use it.

My two requests:

  • Can anybody help me providing fully functional examples of coding GUI using libui?
  • Is anyone aware of any UI builders that can be used for Kotlin|Native?

Thanks a lot in advance.

2

I don’t use native myself but you should be able to use any C library you want so you should take a look at that.

Have you taken a look at the samples in the libui github repo? I don’t know of any others.

Are you just new to kotlin native and GUI or new to programming in general? In either case I would at least consider switching to kotlin jvm, since there are far more GUI libraries out there with much better documentation (libgui seems to be a small open source project with only a few people working on it).
Also if you are new to programming in general kotlin native might be a bit more complicated, because of memory managment, C interop and the fact that it is still in an early access stage.

1 Like
3

Hello community

I came here because I had the same problem, which I believe is not trivial.

I’m an experienced developer in GUI libraries, mostly Swing/iOS/Android, but also (not so much) GTK/QT.

But I am rather new with Kotlin/Native. I still struggle the (also) missing examples in cases that don’t directly affect iOS development or even posix code.

The need of a UI for a native development key, I think it’s self obvious. But today, the libui plugin that got mentioned is not working any more (probably is not any more supported kotlin natime 1.5) , the gtk-kt also fails to run and gtk-kn is so new, that not even artifacts exist. In contrast, Rust and Go have special pages, or at least they are considering it.

The experience I’d be waiting, and even willing to help as an experienced Java & Kotlin/JVM developer, would be to add a dependency and then to be able to have some ready-to-use GUI libraries on my code. The experience I have right now is frustration, missing documentation, unreplied questions or even negative comments.

So the original question is more relevant than ever: is there any GUI for Kotlin/Native that could be useful?

4

Is there a very specific reason you need to use Kotlin/Native specifically?

In Kotlin/JVM you could of course use any Java-based library, but Compose Multiplatform is made for Kotlin and is great to work with. In fact it’s probably the reason why Kotlin doesn’t have pages like those for Rust or Go, because Compose came as an endorsed UI solution by Jetbrains almost at the same time as Kotlin Multiplatform entered alpha, at which point Kotlin/Native itself was little known.

5

Is there a very specific reason you need to use Kotlin/Native specifically?

Of course there is, but I believe the reasons are self-evident. I’ll comment only about Compose Multiplatform, which is more relevant as an answer.

For me, this is a bad alternative. Is it multi-platform? Yes. But the L&F and user experience is far away from what someone has used to on the desktop. It is mobile-oriented and it is good for what it does, but nothing more.

For real world applications, we need something that relies on native controls, so everything will look as it is supposed to do. That’s why projects like libui are precious on this aspect.

6

I see what you mean, fair point.

Since Kotlin/Native has C interop, you can technically create native Windows apps with it through the win32 APIs, and Linux apps through the GTK library. You can also fo macOS through the Objective-C interop as well.

However, its gonna be a very "raw"and manual experience for now, as there are no good libraries abstracting away the C APIs.

For Linux, there’s a new project aiming to create high-level bindings for GTK called gtk-kn, by using the introspection data in GTK’s C API (GTK is optimized for bindings, and has many officially supported one, making codegen easier). Since GTK is multiplatform, that’s the closest you can get.

Of course any multiplatform toolkit, no matter its language, will not look and feel native out of the box, and GTK is no exception. You can still try to mimic the look and feel of the host operating system as close as possible through custom styles. For now the most mature thing would be to use libadwaita with GTK, to match the GNOME style with good adaptivity as well.
There’s also a proposal to integrate the Compose Compiler / Runtime with gtk-kn for reactivity and declarative UI creation, but it’s just a proposal for now.

When it comes to Compose Multiplatform, I understand the concern about it being mobile-focused, but Compose is modular, and the real “mobile” part is compose-material, which is an implementation of Material Design. If you remove that (and it’s encouraged for apps with custom design systems), you can build your own on top of compose-ui and compose-foundation, which are unopinionated for the most part, and build a set of desktop-centric components (I’m actually in the process of doing just that, implementing the Adwaita design system for Compose, will hopefully open-source soon).

If it’s performance that matters, that’s a hairy subject when it comes to UI, as it’s all very relative. UI in general doesn’t tend to be too much of a problem (unless you’re into embedded development, but that’s a different conversation), as it delegates the tough stuff to the GPU anyways, even if you use the JVM for example (e.g. Compose uses Skia under the hood). The other important logic is what matters.

So yeah, trying to get native controls everywhere would mean writing different code for every OS, but if that’s what you want, you can try to glue things together to get it to work. My preferred approach in this case would be to use the languages that are officially supported by each operating system, and then do interop with a shared Kotlin/Native module for all business logic, but IDK how doable is that to be honest. Even in Rust, a systems language with high-level ergonomics, there’s no one-size-fits-all solution, and all their “native” multiplatform UIs use custom drawing, with some mimicking the host OS’s style. Otherwise, the paradigms of each platform are so different which makes getting good, true native UIs from the same code very hard if not impossible.

1 Like
7

Actually, they are not.

8

The same reasons someone wants to use native vs something else, or Kotlin vs something else.

You might believe that Kotlin/Native is not useful. For me it is and I believe for other people too.

9

So, the reason is “because you like it”. It is a good reason, but not self-evident. I love Kotlin native, but I do not find compelling reasons to use it for desktop applications… yet.

10

You exactly destroy your own arguments. It’s not because “I like it”.
You exactly say the opposite, because you don’t like it.

This conversation is not fruitful any more and there’s no reason to continue talking with you about something you clearly don’t like.