Related Tools
  
  
    
      Several useful developer tools have been build around GObject
      technology.  The next sections briefly introduce them and link to
      the respective project pages.
    
  
    
      For example, writing GObjects is often seen as a tedious task. It
      requires a lot of typing and just doing a copy/paste requires a
      great deal of care. A lot of projects and scripts have been
      written to generate GObject skeleton form boilerplate code, or
      even translating higher-level language into plain C.
    
  
  
  
    Vala
    
      From the Vala
      homepage itself: Vala is a new programming language
      that aims to bring modern programming language features to GNOME
      developers without imposing any additional runtime requirements
      and without using a different ABI compared to applications and
      libraries written in C.
    
  
    
      The syntax of Vala is similar to C#. The available compiler
      translates Vala into GObject C code. It can also compile
      non-GObject C, using plain C API.
    
  
  
  
    GObject builder
  
    
      In order to help a GObject class developer, one obvious idea is
      to use some sort of templates for the skeletons and then run
      them through a special tool to generate the real C files.  GOB (or GOB2) is
      such a tool. It is a preprocessor which can be used to build
      GObjects with inline C code so that there is no need to edit the
      generated C code.  The syntax is inspired by Java and Yacc or
      Lex. The implementation is intentionally kept simple: the inline C
      code provided by the user is not parsed.
    
  
  
  
      Graphical inspection of GObjects
  
      
        Yet another tool that you may find helpful when working with
        GObjects is G-Inspector. It
        is able to display GLib/GTK+ objects and their properties.
      
  
  
  
    Debugging reference count problems
  
    
      The reference counting scheme used by GObject does solve quite 
      a few memory management problems but also introduces new sources of bugs.
      In large applications, finding the exact spot where the reference count
      of an Object is not properly handled can be very difficult.
    
    
      A useful tool in debugging reference counting problems is to
      set breakpoints in gdb on g_object_ref() and g_object_unref().
      Once you know the address of the object you are interested in,
      you can make the breakpoints conditional:
      
break g_object_ref if _object == 0xcafebabe
break g_object_unref if _object == 0xcafebabe
      
    
  
    
  
    Writing API docs
  
    The API documentation for most of the GLib, GObject, GTK+ and GNOME
    libraries is built with a combination of complex tools. Typically, the part of 
    the documentation which describes the behavior of each function is extracted
    from the specially-formatted source code comments by a tool named gtk-doc which
    generates DocBook XML and merges this DocBook XML with a set of master XML 
    DocBook files. These XML DocBook files are finally processed with xsltproc
    (a small program part of the libxslt library) to generate the final HTML
    output. Other tools can be used to generate PDF output from the source XML.
    The following code excerpt shows what these comments look like.
      
/**
 * gtk_widget_freeze_child_notify:
 * @widget: a #GtkWidget
 * 
 * Stops emission of "child-notify" signals on @widget. The signals are
 * queued until gtk_widget_thaw_child_notify() is called on @widget. 
 *
 * This is the analogue of g_object_freeze_notify() for child properties.
 **/
void
gtk_widget_freeze_child_notify (GtkWidget *widget)
{
...
      
    
    
    Thorough
    documentation
    on how to set up and use gtk-doc in your project is provided on the
    GNOME developer website.