GObject Introspection

Introduction

The GObject Introspection project is a bit abstract and deserves a better explanation. The goal of the project is to describe the APIs we have in our stack and collect them in a uniform, machine readable format.

Use cases

There are many different uses of this, but to mention a few:

Improve the process of writing language bindings

The situation today in all of our language bindings is that each project has their own way of extracting APIs. There's plenty of details missing in all the different approaches which forces each project to duplicate the additional information.

Public API verification

Sometimes the API of a library in our stack changes by accident. Usually by a less experienced developer making a change without realizing it will break applications. Introspecting the available API in each release of the library and comparing it to the last one makes it easy to see what changed

Documentation tools

The tools written inside of the GObjectIntrospection can easily be reused to improve that problem. Essentially; replacing gtk-doc. We want to document what we export so it makes sense to glue this together with API verification mentioned above (see BindingsDocumentation)

Component System

Knowing the exact API for a certain module allows us to write the glue which makes it possible to call from one module to another. The forms the basis for a component system.

Other uses cases

• Automatic generation of UI (similar to beast)
• UI Designer
• Serialization
• RPC / DBus

See also http://www.flickr.com/photos/vlatheimpaler/2332945173/sizes/l/in/set-72157604115673476/

Contents of the package

It provides:

• 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
• 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

Getting the code

The latest stable release is available from download.gnome.org

SVN can be fetched from:

svn co http://svn.gnome.org/svn/gobject-introspection/trunk gobject-introspection

ViewVC link: http://svn.gnome.org/viewcvs/gobject-introspection/trunk

There's also a separate repository of .gir files, available in the gir-repository module:

svn co http://svn.gnome.org/svn/gir-repository/trunk gir-repository

ViewVC link: http://svn.gnome.org/viewcvs/gir-repository/trunk/gir/

Projects using GObject-Introspection

• Vala - Compiler for the GObject type system (compile time)

• PyBank - Python bindings (runtime)

• Glib-Object-Introspection - Perl bindings (runtime)

• JGIR - Java/JVM bindings (compile time, using typelib)

Projects that could use GObject-Introspection

• Mono GAPI could replace its gapi2-parser by using GOject-Introspection.

• gtkmm could use GObject-Introspection in its gmmproc to generate C++ library bindings

Tasklist

Things to think about

• Repository
  • Reconsider the current clunky API, maybe an iterator approach is better
  • Use hashes?
  • Think about a system-wide repository mapping namespace ids to libraries/metadata files
  • Maybe allow populating repositories at runtime
  • Maybe support invocation of functions using closures (maybe even GClosure) instead of only libffi, so that functions can be implemented in languages other than C. This would require populating the repository with new classes/methods at run-time.
• Some way of saying what allocator is used for transfer parameters?
  • - maybe just set an allocator per module for transfer-out - caller has to use module allocator for transfer-in?
• For more complicated reference types, (pointer to multidimensional array of int pointers) the current Blob structure does not seem sufficient or optimal, how could this be reworked?
• What did Mattias mean by "Sort arrays so that we can use bsearch for lookup"?

Annotations

see GObjectIntrospection/Annotations

Contact

• For questions or additional information, please use:

• Mailing list: gtk-devel-list@gnome.org

• IRC: #introspection on irc.gnome.org