Füllen der zusätzlichen Dateien
Es gibt eine Menge zusätzlicher Dateien, die mit den eingebetteten Quellcode-Kommentaren verwaltet werden müssen: <package>.types, <package>-docs.xml (früher .sgml), <package>-sections.txt.

Bearbeiten der Typendatei
Falls Ihre Bibliothek oder Anwendung GObjects beinhaltet, sollten deren Signale, Argumente/Parameter und Positionen in der Hierarchie in der Dokumentation erscheinen. Alles was Sie tun müssen, ist die xxx_get_type-Funktionen zusammen mit deren Includes in der Datei <package>.types aufzulisten.

Beispiel-Schnipsel einer Typen-Datei

#include <gtk/gtk.h>

gtk_accel_label_get_type
gtk_adjustment_get_type
gtk_alignment_get_type
gtk_arrow_get_type

Seit GTK-Doc 1.8 kann gtkdoc-scan diese Liste für Sie erstellen. Fügen Sie einfach »--rebuild-types« zu SCAN_OPTIONS in Makefile.am hinzu. Wenn Sie so vorgehen sollten Sie weder Typen-Datei mit veröffentlichen noch diese unter Versionsverwaltung stellen.

Bearbeiten des Master-Dokuments
GTK-Doc erstellt die Dokumentation in DocBook-SGML/XML. Beim Verarbeiten der in den Quellcode eingebetteten Kommentare erzeugt GTK-Doc eine Dokumentationsseite pro Klasse oder Modul als separate Datei. Das Hauptdokument schließt diese ein und setzt sie in die passende Reihenfolge.
Während GTK-Doc ein Vorlagen-Hauptdokument für Sie erstellt, wird eine spätere Ausführung es nicht mehr verändern. Das bedeutet, dass Sie das Dokument beliebig strukturieren können. Dies schließt Gruppieren von Seiten und Hinzufügen von zusätzlichen Seiten ein. GTK-Doc hat eine neue Test-Suite, wo auch das Hauptdokument von Grund auf neu erstellt wird. Es ist ratsam, sich diese von Zeit zu Zeit anzusehen und zu schauen, ob dort einige Neuigkeiten eingeführt werden.
Erstellen Sie keine Schritt-für-Schritt-Anleitungen als zusätzliche Dokumente. Schreiben Sie lediglich zusätzliche Kapitel. Der Vorteil des direkten Einbettens einer Anleitung für Ihre Bibliothek in die API ist die Möglichkeit der einfachen Verknüpfung der Schritt-für-Schritt-Anleitung zur Symboldokumentation. Außerdem sind die Chancen größer, dass die Anleitung die gleichen Aktualisierungen erfährt wie die Bibliothek selbst.
Was sollte nun innerhalb des Master-Dokuments geändert werden? Zunächst recht wenig. Es gibt einige Platzhalter (Text in eckigen Klammern), die Sie beachten sollten.

Kopfzeile des Master-Dokuments

<bookinfo>
  <title>MODULENAME Reference Manual</title>
  <releaseinfo>
    for MODULENAME [VERSION]
    The latest version of this documentation can be found on-line at
    <ulink role="online-location" url="http://[SERVER]/MODULENAME/index.html">http://[SERVER]/MODULENAME/</ulink>.
  </releaseinfo>
</bookinfo>

<chapter>
  <title>[Insert title here]</title>

Zusätzlich werden einige Optionselemente in Kommentarform erstellt. Sie können sich diese anschauen und aktivieren, wenn Sie wollen.

Optionaler Teil im Master-Dokument

  <!-- aktivieren Sie dieses, wenn sie gobject introspection-Anmerkungen verwenden
  <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
  -->

Schlussendlich müssen Sie einen neuen Abschnitt explizit einfügen, sobald Sie einen öffnen. Das Werkzeug gtkdoc-check erinnert Sie an neu erzeugte XML-Dateien, die in der Dokumentation noch nicht erfasst sind.

Einbeziehen erzeugter Abschnitte

  <chapter>
    <title>my library</title>
      <xi:include href="xml/object.xml"/>
      ...

Bearbeiten der Abschnittsdatei
Die Abschnittsdatei wird verwendet, um die Dokumentations-Ausgaben von GTK-Doc zu organisieren. Man gibt an, welches Symbol zu welchem Modul oder welcher Klasse gehört und regelt die Sichtbarkeit (öffentlich oder privat).
Die Abschnittsdatei ist eine reine Textdatei mit Markierungen, welche die Abschnitte voneinander trennen. Leere Zeilen werden ignoriert und Zeilen, die mit »#« beginnen, werden als Kommentarzeilen behandelt.
Zwar lassen die Markierungen die Datei wie XML erscheinen, doch der Schein trügt. Bitte schließen Sie keine Markierungen wie <SUBSECTION>.

Einbeziehen erzeugter Abschnitte

<INCLUDE>libmeep/meep.h</INCLUDE>

<SECTION>
<FILE>meepapp</FILE>
<TITLE>MeepApp</TITLE>
MeepApp
<SUBSECTION Standard>
MEEP_APP
...
MeepAppClass
meep_app_get_type
</SECTION>

Die Markierung <FILE> ... </FILE> wird verwendet, um den Dateinamen ohne Suffix anzugeben. Zum Beispiel wird »<FILE>gnome-config</FILE>« dazu führen, dass der Deklarationsabschnitt in die Vorlage-Datei tmpl/gnome-config.sgml ausgegeben wird, welche in die DocBook-XML-Datei sgml/gnome-config.sgml oder die DocBook-XML-Datei xml/gnome-config.xml umgewandelt wird. (Der Name der HTML-Datei basiert auf dem Modulnamen und dem Abschnittstitel. Für GObject basiert er auf dem GObject-Klassennamen in Kleinbuchstaben).
Das Tag <TITLE> ... </TITLE> wird zur Angabe des Abschnitttitels verwendet. Es ist nur nützlich bevor die Vorlagen (falls verwendet) anfangs erstellt werden, weil der Titel in der Vorlage diesen überschreibt. Wenn man das SECTION-Kommentar in den Quellen einsetzt, ist dies überflüssig.
Sie können Objekte im Abschnitt mittels der Markierung <SUBSECTION> gruppieren. Derzeit gibt es eine Leerzeile zwischen Unterabschnitten im Inhaltsangabe-Abschnitt aus. Sie können auch <SUBSECTION Standard> für Standard GObject-Deklarationen verwenden (z.B. Funktionen wie g_object_get_type und Makros wie G_OBJECT(), G_IS_OBJECT() etc.). Derzeit werden diese nicht in die Dokumentation aufgenommen. Sie können auch <SUBSECTION Private> für private Deklarationen verwenden, welche nicht ausgegeben werden. Dies ist eine praktische Möglichkeit, Warnmeldungen bezüglich ungenutzter Deklarationen zu vermeiden. Wenn Ihre Bibliothek private Typen enthält, die nicht in der Objekthierarchie und der Liste der implementierten oder benötigten Schnittstellen erscheinen sollen, fügen Sie diese zu einem »Private«-Unterabschnitt hinzu. Ob Sie GObject oder GObjectClass wie Structs im öffentlichen oder im Standardabschnitt einsetzen, hängt davon ab, ob öffentliche Einträge vorhanden sind (Variablen, vmethods).
Sie können auch <INCLUDE> ... </INCLUDE> verwenden, um die #include-Dateien anzugeben, die in den Abschnitten zur Inhaltsangabe gezeigt werden. Es enthält eine durch Kommata getrennte Liste von #include-Dateien ohne eckige Klammern. Wenn Sie es außerhalb aller Abschnitte festlegen, wirkt es in allen Abschnitten bis zum Dateiende. Wenn Sie es innerhalb eines Abschnitts festlegen, wirkt es nur in diesem Abschnitt.