Rellenar campos adicionales
Existen tres archivos adicionales que deben mantenerse junto con los comentarios en línea del código fuente: <paquete>.types, <paquete>-docs.xml (.sgml en el pasado) y <paquete>-sections.txt.

Editar los tipos de archivo
Si su biblioteca o aplicación incluye GObjects puede querer que sus señales, argumentos y/o parámetros y posición en la jerarquía se muestre en la documentación. Todo lo que debe hacer es listar las funciones xxx_get_type junto con sus «include» en el archivo <paquete>.types.

Fragmento de ejemplo de tipos de archivo

#include <gtk/gtk.h>

gtk_accel_label_get_type
gtk_adjustment_get_type
gtk_alignment_get_type
gtk_arrow_get_type

Desde GTK-Doc 1.8 gtkdoc-scan puede genera esta lista. Simplemente añada «--rebuild-types» a SCAN_OPTIONS en el Makefile.am. Si usa esto no debería ejecutar dist sobre los tipos de archivo ni tenerlos bajo el control de versiones.

Editar la sección maestra del documento
GTK-Doc produce documentación en DocBook SGML/XML. Cuando se procesan los comentarios en las líneas del código, las herramientas de GTK-Doc generan una página de documentación por clase o módulo en un archivo aparte. El documento maestro las incluye y ordena.
Puesto que GTK-Doc crea una documento maestro de plantilla, una posterior ejecución no lo modificará de nuevo. Esto significa que se puede estructurar libremente la documentación. Esto incluye agrupar páginas y añadir páginas adicionales. Ahora GTK-Doc tiene un entorno de pruebas, donde también el documento maestro se vuelve a crear desde cero. Es una buena idea mirarlo de vez en cuando para ver si se han introducido algunas mejoras.
No crear tutoriales como documentos adicionales. Solamente escriba capítulos adicionales. La ventaja de integrar directamente el tutorial para su biblioteca en la documentación de la API es que es fácil para el tutorial enlazar la documentación de símbolos. Además las posibilidades de actualizar el tutorial junto con la biblioteca son mayores.
¿Así que qué es lo que hay que cambiar en el documento maestro? Para empezar es muy poco. Existen algunos «placeholders» (texto entre corchetes) de los que habría que encargarse.

Cabecera del documento maestro

<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>

Se crean además unos pocos elementos de opciones de la manera comentada. Puede revisarlos y activarlos como quiera.

Parte opcional en el documento maestro

  <!-- active esto cuando use anotaciones de introspección de gobject
  <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
  -->

Por último, necesita añadir una sección nueva siempre que quiera introducir una. La herramienta gtkdoc-check le recordará los nuevos archivos xml generados que no estén inclídos todavía en la documentación.

Incluir secciones generadas

  <chapter>
    <title>mi biblioteca</title>
      <xi:include href="xml/object.xml"/>
      ...

Editar el archivo de sección
El archivo de sección se usa para organizar la salida de la documentación por GTK-Doc. Aquí se especifica qué símbolos pertenecen a qué módulo o clase y el control de la visibilidad (pública o privada).
El archivo de sección es un archivo de texto plano con etiquetas que delimitan las secciones. Se ignoran las líneas vacías y las líneas que comiencen con «#» se tratan como comentarios.
Aunque las etiquetas hacen que el archivo parezca XML, no lo es. No incluya etiquetas del tipo <SUBSECTION>.

Incluir secciones generadas

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

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

La etiqueta <FILE> ... </FILE> se usa para especificar el nombre del archivo, sin sufijo. Por ejemplo, usar «<FILE>gnome-config</FILE>» dará como resultado en la sección de declaraciones la salida tmpl/gnome-config.sgml en el archivo de plantilla, que se convertirá al archivo DocBook XML sgml/gnome-config.sgml o al archivo DocBook XML xml/gnome-config.xml. (El nombre del archivo HTML está basado en el nombre del módulo y en el título de la sección, o para GObjects está basado en el nombre de clase de GObject convertido a minúscula.)
La etiqueta <TITLE> ... </TITLE> se usa para especificar el título de una sección. Sólo es útil antes de que las plantillas (si se usan) se creen inicialmente, ya que el título configurado en la plantilla lo sobrescribe. Además, si una usa comentarios SECTION en los fuentes, se queda obsoleto.
Puede agrupar elementos en la sección usando la etiqueta <SUBSECTION>. Actualmente esto genera una línea en blanco entre subsecciones en la sección de resumen. También puede usar <SUBSECTION Standard> para declaraciones estándar de GObject (ej. funciones como g_object_get_type and macros como G_OBJECT(), G_IS_OBJECT() etc.). Actualmente éstas se han dejado fuera de la documentación. También puede usar <SUBSECTION Private> para declaraciones privadas que no producirán ninguna salida (s una manera práctica de evitar mensajes de advertencia sobre declaraciones sin usar). Si sus bibliotecas contienen tipos privados que no quiere que aparezcan en la jerarquía de objetos o en la lista de interfaces implementados o necesarios, añádalos a una subsección Privada. Si ubica GObject y GObjectClass como estructuras en la sección pública o estándar, depende de si tienen entradas públicas (variables, vmethods).
También puede usar <INCLUDE> ... </INCLUDE> para especificar qué archivos #include se muestran en la sección de resumen. Contiene una lista de archivos #include separados por comas, sin las almohadillas. Si lo configura fuera de cualquier sección, actúa para todas las secciones hasta el final del archivo. Si lo configura dentro de una sección, sólo se aplica a esa sección.