Fylla i de extra filerna
Det finns ett antal extra filer som behöver underhållas tillsammans med de infogade källkodskommentarerna: <paket>.types, <paket>-docs.xml (tidigare .sgml), <paket>-sections.txt.

Redigera typfilen
Om ditt bibliotek eller program inkluderar GObject så kommer du att vilja att deras signaler, argument/parametrar och position i hierarkin visas i dokumentationen. Allt du behöver göra är att lista xxx_get_type-funktionerna tillsammans med deras huvudfil i filen <package>.types.

Exempel på typfilsnutt

#include <gtk/gtk.h>

gtk_accel_label_get_type
gtk_adjustment_get_type
gtk_alignment_get_type
gtk_arrow_get_type

Sedan GTK-Doc 1.8 kan gtkdoc-scan generera denna lista åt dig. Lägg bara till ”--rebuild-types” i SCAN_OPTIONS i Makefile.am. Om du använder detta tillvägagångssätt bör du inte distribuera typfilen eller versionshantera den.

Redigera huvuddokumentet
GTK-Doc producerar dokumentation i DocBook SGML/XML. När infogade källkodskommentarer behandlas genererar GTK-Doc en dokumentationssida per klass eller modul som en separat fil. Huvuddokumentet inkluderar dem och placerar dem i en ordning.
Även om GTK-Doc skapar en mall för huvuddokumentet åt dig kommer senare körningar inte att röra det igen. Detta innebär att man är fri att strukturera om dokumentationen. Detta inkluderar att gruppera sidor och lägga till extra sidor. GTK-Doc har numera en testsvit där också huvuddokumentet återskapas från grunden. Det är en bra idé att titta på detta då och då för att se om några nya godsaker införts där.
Skapa inte handledningar som extra dokument. Skriv bara extra kapitel. Fördelen med att bädda in handledningen direkt i ditt biblioteks gränssnittsdokumentation är att det är enkelt att länka från handledningen till symboldokumentationen. Inbäddad är det större chans att handledningen blir uppdaterad tillsammans med biblioteket.
Så vilka saker ska ändras i huvuddokumentet? I början är det väldigt lite. Det finns en del platshållare (text i hakparenteser) som du bör ta hand om.

Huvuddokumentets huvud

<bookinfo>
  <title>MODULNAMN handbok</title>
  <releaseinfo>
    för MODULNAMN [VERSION]
    Den senaste versionen av detta dokument kan hittas på nätet på
    <ulink role="online-location" url="http://[SERVER]/MODULNAMN/index.html">http://[SERVER]/MODULNAMN/</ulink>.
  </releaseinfo>
</bookinfo>

<chapter>
  <title>[Infoga titel här]</title>

Dessutom finns det ett antal valfria element som skapas i kommenterad form. Du kan granska dessa och aktivera dem enligt dina egna önskemål.

Valfri del i huvuddokumentet

  <!-- aktivera detta om du vill använda gobject introspection-noteringar
  <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
  -->

Slutligen behöver du lägga till ett nytt avsnitt när du infogar det. Verktyget gtkdoc-check kommer att påminna dig om nyligen genererade xml-filer som ännu inte infogats i dokumentationen.

Inkludera genererade avsnitt

  <chapter>
    <title>mitt bibliotek</title>
      <xi:include href="xml/object.xml"/>
      ...

Redigera avsnittsfilen
Avsnittsfilen används för att organisera dokumentationsutdata från GTK-Doc. Här kan man ange vilken symbol som hör till vilken modul eller klass och styra synligheten (publik eller privat).
Avsnittsfilen är en vanlig textfil med taggar som avgränsar avsnitt. Blankrader ignoreras och rader som börjar med ett ”#” behandlas som kommentarsrader.
Även om taggarna får filen att se ut som xml, är det inte det. Avsluta inte taggar så som <SUBSECTION>.

Inkludera genererade avsnitt

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

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

Taggen <FILE> … </FILE> används för att ange filnamnet, utan något suffix. Om man t.ex. använder ”<FILE>gnome-config</FILE>” blir resultatet att avsnittsdeklarationerna matas ut i mallfilen tmpl/gnome-config.sgml, som kommer att konverteras till DocBook XML-filen xml/gnome-config.sgml eller DocBook XML-filen xml/gnome-config.xml. (Namnet på HTML-filen baseras på modulnamnet och avsnittstiteln, för GObject baseras det på klassnamnet för GObjectet konverterat till gemener).
Taggen <TITLE> … </TITLE> används för att ange titeln på avsnittet. Det är bara användbart före mallar skapas initialt (om de används), eftersom titeln som ställs in i avsnittsfilen åsidosätter denna. Vidare är detta föråldrat om man använder SECTIONS-kommentarer i källkoden.
Du kan gruppera objekt i avsnittet genom att använda taggen <SUBSECTION>. För närvarande matas en blankrad ut mellan underavsnitt i sammanfattningsavsnittet. Du kan också använda <SUBSECTION Standard> för standard GObject-deklarationer (t.ex. funktioner så som g_object_get_type och makron som G_OBJECT(), G_IS_OBJECT(), etc.). För närvarande utelämnas dessa ur dokumentationen. Du kan också använda <SUBSECTION Private> för privata deklarationer som inte kommer att matas ut (det är ett bekvämt sätt att undvika varningsmeddelanden om oanvända deklarationer). Om ditt bibliotek innehåller privata typer som du inte vill ska dyka upp i objekthierarkin och i listan över implementerade eller krävda gränssnitt, lägg till dem i ett privat avsnitt. Huruvida du vill placera GObject och GObjectClass-liknande strukturer i publika eller standardavsnitt beror på om de har publika poster (variabler, virtuella metoder).
Du kan också använda <INCLUDE> ... </INCLUDE> för att ange #include-filerna som ska visas i sammanfattningsavsnitten. Den innehåller en kommaavgränsad lista av #include-filer, utan vinkelparenteser. Om du ställer in det utanför några avsnitt kommer det att påverka alla avsnitt tills slutet på filen. Om du ställer in det inom ett avsnitt kommer det bara att påverka det avsnittet.