Introducing gtk-kn: GTK for Kotlin/Native We've been working on generating Kotlin Native bindings for GTK and other GObject Introspection-based libraries (Gio, Pango, Adwaita, GtkSourceView,...) A quick non-exhaustive list of what is already possible right now: • Build UI in code using widgets from the Gtk4 and Adwaita libraries • Load and use

.ui

resource files • Connect signal handlers • Use property binding on all objects and widgets • Work with `ListModel`/`ListStore`/`Listview` • Define your own

GObject

types with support for properties • Use various Gio abstractions including the file system API, menus, actions and resources We have not published the artefacts to MavenCentral yet. However, you can still use it in your projects by building locally and deploying to MavenLocal. The current focus is on Linux, but we're also looking at Windows/MacOS support in the future. We would love to hear some feedback on the project, so if you're interested in testing it out, head over to our GitLab page https://gitlab.com/gtk-kn/gtk-kn to learn more. Also, if you have any questions or want to get involved in development discussions, we mostly hang out on our Matrix room at https://matrix.to/#/#gtk-kn:matrix.org.

Hey! I'm the author of #decouple. My goal is to create a Compose-based widget set that is truly native on all platforms (DOM on the web, GTK on Linux…). This is done by creating a common module that declares components as interfaces, and implementing them on each platform by delegating to feature-full libraries. The project is currently a prototype that demonstrates this is, in fact, feasible—but it needs a lot more breadth before being usage in real projects. I'm very interested in talking about your experience making this library, would that be interesting to you?

Sure, I'm always happy to talk about it and share experiences. I'm available here on the Kotlin Slack and the Matrix space

macosArm64 🙂

Very nice! Did you need lots of changes to the def files? And are you interested in contributing this work?

Install the dependencies via

homebrew

:

brew install libadwaita
brew install gdk-pixbuf
brew install gobject-introspection
brew install gtk4
brew install pango
brew install libpango
brew install libconfig

and apply the attached patch (basically the changes for the

cflags

and

libs

). The right values are provided for example as

/opt/homebrew/bin/pkg-config --libs libadwaita-1

(note the

pkg-config

from

homebrew

, not from system) It is little bit quick and dirty 😄 The "problems" to solve are: •

gio/gdesktopappinfo.h

vs

gio/gosxappinfo.h

•

girBaseDir

PS: enabled the basic c support over

#language=c

in

.def

files 😄

Thanks a lot for this already, I expected issues with things like

gdesktopappinfo

, it is on my todo list for macos and windows support but focus has mainly been on the generator itself for now. The current idea is to not officially support macos/windows on the master branch yet, but keep alternative "unsupported" branches in the repo containing the "quickfix" patches until I find some time to properly support it.

This was the first running version. What is to do, is to replace the fixed versions in path with related ones, for example:

$ ls -l /opt/homebrew/include/glib*
/opt/homebrew/include/glib-2.0 -> ../Cellar/glib/2.76.1/include/glib-2.0/

work is ongoing for a gradle plugin, and that work already supports invoking

pkg-config

for an unrelated thing (resource compilation). Eventually we would like to also run

pkg-config

for the .def files, so that should fix the paths

Eventually we would like to also run

pkg-config

for the .def files, so that should fix the paths

Basically yes, but not 1:1, because for example this was added extra by me:

-DGDK_PIXBUF_ENABLE_BACKEND=1

I also expected some changes required on different platforms, which is why I want to take some time later to figure out how we can get it all nice and integrated into the build, and we can "get by" with some temporary windows/macos branches until those build changes land

@vbsteven I can create a merge request with this patch, if you want. Or as you said, an experimental branch with support. 😉

an MR would be very much appreciated, You can mark it as

draft

and point it to master for now, and I'll create the platform branches and update the MR target branch when I get to it