Introduction to GObject Introspection

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:

== 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:

And the gobject-introspection and gir-repository modules in GNOME SVN.
This entry was posted in Blogroll, General, GNOME, olpc, PyGTK, Python. Bookmark the permalink.

7 Responses to Introduction to GObject Introspection

  1. lucasr says:

    Dude, this is amazing work! Thanks!

  2. kripken says:

    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?

  3. johan says:

    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.

  4. Carl Fredrich Bolz says:

    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!

  5. johan says:

    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.

  6. Carl Fredrich Bolz says:

    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).

  7. 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…

Leave a Reply

Your email address will not be published. Required fields are marked *