This was also sent to gtk-devel today:
== Introduction == GObject-introspection is a package which will collect and extend the API metadata for GObject based libraries. The main motivation of this work is to centralize all introspection information required to write a language binding. There are many other use cases as well, some of them are described at: http://live.gnome.org/GObjectIntrospection/ == Current status == The GObject-Introspection module/tarball contains the following: * An XML format called GIR containing introspection information * python package to create and parse the GIR format * scanner to generate GIR format from C source and headers These components are also included, but needs to be ported to the GIR format: * a typelib similar to xpcom/msole which stores the information on disk in a binary format * a compiler to compile the typelib from a xml format (and vice versa) * C library to read the typelib A separate SVN module called gir-repository has been created. The idea is to create .gir files of all libraries available in the the whole stack which language bindings can depend on. Eventually the plan is to move the .gir files into the upstream projects themselves, but that's likely to be a long process. == GIR XML Format == The core of the GObject-introspection is an XML format which is called GIR ( GObject Introspection Repository) which contains the API introspection metadata for a library or interface entity. GIR currently contains three different XML namespaces:
- core: contains features available in popular programming languages: classes, methods, functions, interfaces, properties, strings, enums etc.
- c: contains features specific to the C language: identifiers, symbol names, C types
- glib: contains features specific to GLib/GObject: signal, GType, flags, paramspec
The separation of different data in different namespaces allow you to reuse it allows you to arbitrarily extend the metadata available in different languages. == Scanner == To be able to bootstrap the effort and make something which will be available in a reasonable timeframe we've been working on a scanner which parsers C sources and headers and extracts the metadata and generates a GIR file. This is likely to be used by most of the Gtk/GNOME stack, as it would require the least amount of work, however it's not the only way to use the GIR format nor GObject-Introspection. In the future we might use something similar to CORBA IDL to define the interface, as GIR is not meant to human editable. In addition to the parsing the C headers, additional metadata will be provided, likely by using source annotations in gtk-doc comments. == Typelib == To be able to create efficient read introspection data we need a typelib, eg an efficent disk format with a C API to access the internal data. Matthias wrote one based on the XPCOM typelib which has not yet been updated to the GIR format, it's instead the tools to compile it are still using an older XML format. The work on finishing the typelib is depending on having the GIR format somewhat stable and at that point updating the existing tools to understand it. == How can I help? == At this point I'd like to get more eyes at the current GIR format to make sure that it contains the necessary information and in a way which will be easy to parse/access. I am currently working mainly on the scanner to be able to quickly get a large amount API expressed in GIR files. For more information, check out the wiki page: http://live.gnome.org/GObjectIntrospection/ And the gobject-introspection and gir-repository modules in GNOME SVN.
Dude, this is amazing work! Thanks!
I seem to recall something about using GObject-Introspection to automatically create Python bindings in runtime. Do I remember correctly, and if so, how close are we to getting to that?
Pretty far, we need a proper typelib first. After that pybank needs some love to support that.
Its a worthwhile goal, but its further ahead, I’ll be focusing on languages which generate code for now, such as vala or pygtk.
Further ahead or not, I am really looking forward to it. It’s the only realistic chance of getting GTK bindings for PyPy. Thanks for doing this work!
Carl: Having multiple Gtk+ bindings for reach runtime is not ideal.
PyPy should either follow IronPython’s lead and implement enough of the CPython api to be able to run the extensions specific to CPython or start looking into abstracting the current Gtk+ bindings to be implementation independent.
Johan: While I agree that it would be nice to have a way to write extension modules that run with all the various Python implementations, I don’t think it is realistic to use the normal CPython extension modules for that. I don’t think the work of the IronPython guys to support CPython extension modules will be going anywhere. It’s basically one huge hack at the moment and I don’t really see a way to implement it cleanly. The memory model that the extension modules expect (having reference counted C structures) is just too different from that of .NET, which has a safe object model with a moving GC.
Besides, there are quite some extension modules that don’t just use the official API but poke around in the object internals, which obviously cannot be supported at all.
If you want one binding for all runtimes your chances are much better if you do them with ctypes. Sure, ctypes isn’t the nicest thing ever, but at least it is mostly independent of the underlying Python implementation. In fact, both CPython and PyPy already support it and there was a SoC-proposal to implement it for Jython (I don’t remember whether it got accepted).
Today I found your work on GObject/Gtk language bindings. I have written lua-gtk, which uses automatically generated information about types, classes etc., but by parsing the output of gccxml. Quite similar to what you’re working on, isn’t it? By using compile-time generated minimal perfect hashes with the data, code and data size is kept small. Link to the project’s website included…