docs/reference/gobject/tut_tools.xml

   1 <?xml version='1.0' encoding="UTF-8"?>
   2 <!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3                "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
   4 ]>
   5 <part label="V">
   6   <title>Related Tools</title>
   7
   8   <partintro>
   9     <para>
  10       Several useful developer tools have been build around GObject
  11       technology.  The next sections briefly introduce them and link to
  12       the respective project pages.
  13     </para>
  14
  15     <para>
  16       For example, writing GObjects is often seen as a tedious task. It
  17       requires a lot of typing and just doing a copy/paste requires a
  18       great deal of care. A lot of projects and scripts have been
  19       written to generate GObject skeleton form boilerplate code, or
  20       even translating higher-level language into plain C.
  21     </para>
  22   </partintro>
  23
  24   <chapter id="tools-vala">
  25     <title>Vala</title>
  26     <para>
  27       From the <ulink url="https://wiki.gnome.org/Projects/Vala">Vala
  28       homepage</ulink> itself: <quote>Vala is a new programming language
  29       that aims to bring modern programming language features to GNOME
  30       developers without imposing any additional runtime requirements
  31       and without using a different ABI compared to applications and
  32       libraries written in C.</quote>
  33     </para>
  34
  35     <para>
  36       The syntax of Vala is similar to C#. The available compiler
  37       translates Vala into GObject C code. It can also compile
  38       non-GObject C, using plain C API.
  39     </para>
  40   </chapter>
  41
  42   <chapter id="tools-gob">
  43     <title>GObject builder</title>
  44
  45     <para>
  46       In order to help a GObject class developer, one obvious idea is
  47       to use some sort of templates for the skeletons and then run
  48       them through a special tool to generate the real C files.  <ulink
  49       url="http://www.5z.com/jirka/gob.html">GOB</ulink> (or GOB2) is
  50       such a tool. It is a preprocessor which can be used to build
  51       GObjects with inline C code so that there is no need to edit the
  52       generated C code.  The syntax is inspired by Java and Yacc or
  53       Lex. The implementation is intentionally kept simple: the inline C
  54       code provided by the user is not parsed.
  55     </para>
  56   </chapter>
  57
  58   <chapter id="tools-ginspector">
  59       <title>Graphical inspection of GObjects</title>
  60
  61       <para>
  62         Yet another tool that you may find helpful when working with
  63         GObjects is <ulink
  64         url="http://sourceforge.net/projects/g-inspector">G-Inspector</ulink>. It
  65         is able to display GLib/GTK+ objects and their properties.
  66       </para>
  67   </chapter>
  68
  69   <chapter id="tools-refdb">
  70     <title>Debugging reference count problems</title>
  71
  72     <para>
  73       The reference counting scheme used by GObject does solve quite
  74       a few memory management problems but also introduces new sources of bugs.
  75       In large applications, finding the exact spot where the reference count
  76       of an Object is not properly handled can be very difficult.
  77     </para>
  78     <para>
  79       A useful tool in debugging reference counting problems is to
  80       set breakpoints in gdb on g_object_ref() and g_object_unref().
  81       Once you know the address of the object you are interested in,
  82       you can make the breakpoints conditional:
  83       <programlisting>
  84 break g_object_ref if _object == 0xcafebabe
  85 break g_object_unref if _object == 0xcafebabe
  86       </programlisting>
  87     </para>
  88   </chapter>
  89
  90   <chapter id="tools-gtkdoc">
  91     <title>Writing API docs</title>
  92
  93     <para>The API documentation for most of the GLib, GObject, GTK+ and GNOME
  94     libraries is built with a combination of complex tools. Typically, the part of
  95     the documentation which describes the behavior of each function is extracted
  96     from the specially-formatted source code comments by a tool named gtk-doc which
  97     generates DocBook XML and merges this DocBook XML with a set of master XML
  98     DocBook files. These XML DocBook files are finally processed with xsltproc
  99     (a small program part of the libxslt library) to generate the final HTML
 100     output. Other tools can be used to generate PDF output from the source XML.
 101     The following code excerpt shows what these comments look like.
 102       <informalexample><programlisting>
 103 /**
 104  * gtk_widget_freeze_child_notify:
 105  * @widget: a #GtkWidget
 106  *
 107  * Stops emission of "child-notify" signals on @widget. The signals are
 108  * queued until gtk_widget_thaw_child_notify() is called on @widget.
 109  *
 110  * This is the analogue of g_object_freeze_notify() for child properties.
 111  **/
 112 void
 113 gtk_widget_freeze_child_notify (GtkWidget *widget)
 114 {
 115 ...
 116       </programlisting></informalexample>
 117     </para>
 118     <para>
 119     Thorough
 120     <ulink url="https://developer.gnome.org/gtk-doc-manual/stable/">documentation</ulink>
 121     on how to set up and use gtk-doc in your project is provided on the
 122     <ulink url="https://developer.gnome.org/">GNOME developer website</ulink>.
 123     </para>
 124   </chapter>
 125 </part>