The girepository API is meant to be used by dynamic languages—Perl, Python, JavaScript, Ruby, etc. It’s always been the case. Additionally, it’s meant to be used on top of a binding that at least knows how to deal with GType—so, GObject, interfaces, boxed types, enumeration types, etc. The API was created to bridge the ad hoc calling code that existed in various language bindings, so it reflects the requirements of those bindings.
Rust uses GIR data to generate the various trampolines. See the gir crate.
You mean girepository. The GIR data is part of gobject-introspection.
Suit yourself, but you’re definitely using it not as it’s meant to be used.
Just because other people do it doesn’t mean they are right.
Of course you can use girepository—it’s software, anything’s possible. Except that, sooner or later, you’ll hit issues with its API, which was created for dynamic languages. One issue being: not all metadata in the GIR finds its way into the typelib loaded by girepository because:
the data required by dynamic languages is not as comprehensive, given their different type system
the typelib format has more constraints on its binary interface, unlike the XML
Of course, you’re also absolutely free to disregard anything I said, and keep trying to rediscover how GObject and introspection work from first principles, while piling on effort because of the Sunk Cost Fallacy. I mean: it’s your prerogative.
Yes, that is true. For Nim we have now multiple binding generators. I started with c2nim 4 years ago, which usually works fine processing C headers, but c2nim had some problems with all the gtk macros, and another problem was, that we had to reorder data types, as Nim compiler did not support forward declarations of types that time. Now we have also other tools for processing C header files, some clang related. But the problem with C headers is always that it contains not enough information.
I think the idea of gobject-introspection is ok, and generally works good. But as always with GTK the problem is that gtk community is nearly non existent, and while general GTK API is good, gobject-introspection API is not that good.
Note that with current version 0.6 of Nim GTK bindings you will be listed as one of the supporters of the bindings
Funny fact: I just found exactly what I was looking for:
