GObject Introspection

The introspection project has two major goals, and a variety of more minor ones.

Two level applications - C and <your favorite runtime>

It makes sense to build many kinds of applications using (at least) two different levels and languages. Those being C+GObject, and a managed (GC'd) runtime. C is good for graphics, multimedia, and lower level systems work. However, writing complex software is difficult and error-prone without garbage collection. A managed runtime such as JavaScript, Python, Java, Lua, .NET, Scheme etc. makes a lot of sense for non-fast-path application logic such as configuration, layout, dialogs, etc.

Thus, one of the major goals of the GObject introspection project is to be a convenient bridge between these two worlds, and allow you to choose the right tool for the job, rather than being limited inside one or the other. With the introspection project, you can write for example a ClutterActor or GtkWidget subclass in C, and then without any additional work use that class inside JavaScript.

Sharing binding infrastructure work, and making the platform even more binding friendly

Historically in GNOME, the core platform has been relatively binding friendly, but there are several details not captured in the C+GObject layer that bindings have needed. For example, reference counting semantics and the item type inside GLists. Up until now various language bindings such as Python, Mono, java-gnome etc. had duplicated copies of hand-maintained metadata, and this led to a situation where bindings tended to lag behind until these manual fixups were done, or were simply wrong, and your application would crash when calling a more obscure function.

The introspection project solves this by putting all of the metadata inside the GObject library itself, using annotations in the comments. This will lead to less duplicate work from binding authors, and a more reliable experience for binding consumers.

Additionally, because the introspection build process will occur inside the GObject libraries themselves, a goal is to encourage GObject authors to consider shaping their APIs to be more binding friendly from the start, rather than as an afterthought.

Additional goals and uses

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

• UI Designer infrastructure
• 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

GObject Introspection is now stored in git and can be fetched:

git clone git://git.gnome.org/gobject-introspection

CGit link: http://git.gnome.org/cgit/gobject-introspection/tree/

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

git clone git://git.gnome.org/gir-repository

CGit link: http://git.gnome.org/cgit/gir-repository/tree/

Tutorial for application embedding

GObjectIntrospection/FromHereToThere is a tutorial on how to use the introspection system to create multilevel (polyglot) applications.

Runtime bindings based on GObject-Introspection

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

• PyBank - Python bindings (runtime)

• GTK2-Perl/Introspection - Perl bindings (runtime)

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

• Gjs - Javascript (spidermonkey) bindings (runtime)

• Seed - Javascript (JSCore, WebKit JS engine) bindings (runtime)

• sbank - Scheme binding for gobject-introspection (runtime)

• GObjectIntrospection/GObjectConsume - Qt bindings (compile time)

Projects using GObject Introspection

• GnomeShell - prototyping the future gnome shell

Libraries with GObject Introspection support

• See GObjectIntrospection/UpstreamStatus

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

Check bugzilla, glib product, introspection component.

Also see GObjectIntrospection/OldTasklist

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