Migrate to GObject Introspection

[ekd123]

As everybody knows, GTK+3.0 comes with GObject Introspection, a dynamic language binding framework. Now many libraries support other languages with it. If we can use GObject Introspection, that means we've got many libraries for use (and GTK too)!

[Blei]

Sorry for the slow response, I was in Greece for a week ^^

What would be the advantage of using GObject Introspection vs. creating bindings by parsing .h files? And what exactly is meant by "supporting" GIS? A program akin to bindgen, but for .gir files?

[ekd123]

Using GObject Introspection means we won't support them by ourselves and they are supported directly by the GTK+ team (we just parse the gir files). And if we do, we'll get a lot of other libraries which implemented GI. And we don't need to regenerate the binding after a update.

GI supporting can be either compile-time or runtime. I don't know if Clay are flexible enough to play with the compile-time support. But though, runtime can always be implemented.

https://live.gnome.org/GObjectIntrospection/HowToWriteALanguageBinding

[Blei]

Hmm, I don't see how we could implement runtime bindings. Clay is a pretty statically typed language after all.

So we would have to generate some clay bindings, either from the .gir or the .typelib files, ahead of time. These bindings would then have to be regenerated after an update, as before.

Maybe I'm missing something? Or do you maybe mean integrating GI into the clay compiler?

[ekd123]

Vala integrated GI into the compiler and it works. I don't know whether the upstream would agree integrating it.

[Blei]

Yeah, integration of GI into the compiler could be interesting... Maybe open a ticket there?

But for this project, I still don't see the upside of using GI vs. running bindgen on the .h files. Maybe I'm still missing something.

[ekd123]

GI is more likely to be a dynamic binding like

import gi.gtk; // here we don't generate anything about that. just runtime
main () {
var win = Window();
}

just write a dynamic module for Clay, that asks the GI Library to parse, and it does some magic, so we can use it just like a normal class or function. We don't need to do anything after an update.

However I don't know if Clay can do that. :-( in fact, we still can make it a normal module. but it will lose all of the advantages. If Clay can't do that, maybe we must integrate it into the compiler

[Blei]

I'm pretty sure this is not possible unless someone integrates GI into the compiler. I guess you'd have to open an issue in the clay repo and see what jckarter thinks about this.

[ekd123]

jckarter/clay#290