Next: , Up: Introduction   [Contents][Index]

1.1 The Concept of Operations

GNU Guile itself does not provide its own graphical user interface (GUI) programming toolkit; it needs to incorporate an existing GUI toolkit. Of the existing GUI toolkits, GTK has been designed with the goal of being language agnostic, usable with any programming language.

The application program interface (API) for GTK is large, with dozens of classes and hundreds of functions. It consist of several sub-projects: GTK+, GDK, Pango, GLib and many others. These APIs change from version to version. Creating a binding by hand – wrapping each type and function for use with Guile and then keeping it up do date – would be a laborious task. Knowing this, GTK provides a way to query information about the classes and functions it provides so that a binding may be generated programmatically. Instead of creating a Guile binding for all of GTK and it subprojects, we create a Guile binding for its introspection layer, and then use that information to make a Guile binding for all of GTK.

To make a Guile binding for the introspection layer, we need to wrap three application program interfaces.

  1. The GLib Dynamic Type System
  2. GObject - the fundamental base class for all object types in GTK+
  3. GIRepository - the GObject introspection repository manager

Then, using information queried from these 3 API, a binding for GTK can be made programmatically. As a bonus, a binding to any project that adheres to GObject standards can be created as well.

Next: Installation, Up: Introduction   [Contents][Index]