Preenchendo os arquivos extras
Há alguns poucos arquivos extras, que precisam ser mantidos junto com os comentários inseridos no código fonte: <pacote>.types, <pacote>-docs.xml (no passado, .sgml), <pacote>-sections.txt.

Editando o arquivo de tipos
Se sua biblioteca ou aplicativo inclui GObjects, você deseja que seus sinais, argumentos/parâmetros e posição na hierarquia sejam mostrados na documentação. Tudo que você precisa fazer é listar as funções xxx_get_type junto com seus include dentro do arquivo <pacote>.types.

Trecho de exemplo de arquivo de tipos

#include <gtk/gtk.h>

gtk_accel_label_get_type
gtk_adjustment_get_type
gtk_alignment_get_type
gtk_arrow_get_type

Desde o GTK-Doc 1.8, o gtkdoc-scan pode gerar esta lista para você. Basta adicionar “--rebuild-types” a SCAN_OPTIONS no Makefile.am. Se você usar esta abordagem, você não deveria distribuir o arquivo de tipos nem tê-lo sob um controle de versão.

Editando o documento mestre
O Gtk-Doc produz documentação em DocBook SGML/XML. Ao processar os comentários inseridos nos fontes, as ferramentas do GTK-Doc geram uma página de documentação por classe ou módulo como um arquivo separado. O documento mestre os inclui e os coloca em uma ordem.
Enquanto o Gtk-Doc cria um modelo de documento mestre para você, execuções posteriores não vão tocá-lo novamente. Isso significa que se pode estruturar a documentação livremente. Isso inclui agrupamento de páginas e adição de páginas extras. O Gtk-Doc agora possui uma suíte de teste, na qual também o documento mestre é recriado do zero. É uma boa ideia verificar isso de tempo em tempo para ver se há itens a serem introduzidos lá.
Não crie tutoriais como documentos extras. Apenas escreva capítulos extras. O benefício de embutir diretamente o tutorial para sua biblioteca na documentação da API é que é mais fácil vincular o tutorial a um símbolo da documentação. Além disso, as chances são mais altas que o tutorial obtenha atualizações junto com a biblioteca.
Então, quais são as coisas para se alterar dentro do documento mestre? Para começar é apenas um pouco. Existem alguns mantedores de espaço (texto em colchetes) que você deve cuidar.

Cabeçalho do documento mestre

<bookinfo>
  <title>Manual de referência do NOMEDOMÓDULO</title>
  <releaseinfo>
    for NOMEDOMÓDULO [VERSÃO]
    A última versão desta documentação também pode ser encontrada on-line em
    <ulink role="online-location" url="http://[SERVIDOR]/NOMEDOMÓDULO/index.html">http://[SERVIDOR]/NOMEDOMÓDULO/</ulink>.
  </releaseinfo>
</bookinfo>

<chapter>
  <title>[Insira o título aqui]</title>

Além disso, alguns elementos de opção são criados na forma comentada. Você pode revisá-los e habilitá-los como preferir.

Parte opcional do documento mestre

  <!-- habilite isso se você usa anotações do gobject introspection
  <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
  -->

Finalmente você precisa adicionar nova seção sempre que você a introduzir. A ferramenta gtkdoc-check vai lembrar você de arquivos xml recentemente gerados que ainda não foram incluídos na documentação.

Incluindo seções geradas

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

Editando o arquivo de seção
O arquivo de seção é usado para organizar a saída da documentação pelo GTK-Doc. Aqui pode-se especificar qual símbolo pertence a qual módulo ou classe e controla a visibilidade (pública ou privada).
O arquivo de seção é uma arquivo texto simples com seções delimitadas por tags. Linhas em branco são ignoradas e linhas começando com um “#” são tratadas como linhas de comentários.
Enquanto as tags fazem o arquivo se parecer xml, ele não é. Por favor, não feche tags como <SUBSECTION>.

Incluindo seções geradas

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

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

A tag <FILE> ... </FILE> é usada para especificar o nome de arquivo, sem qualquer sufixo. Por exemplo, ao usar “<FILE>gnome-config</FILE>” resultará nas declarações da seção serem retornadas no arquivo modelo tmpl/gnome-config.sgml, o qual será convertido no arquivo DocBook XML xml/gnome-config.sgml ou no arquivo DocBook XML xml/gnome-config.xml. (O nome do arquivo HTML é baseado no nome do módulo e no título da seção ou, para GObjects, é baseado no nome da classe GObjects convertidos os caracteres para minúsculos).
A tag <TITLE> ... </TITLE> é usada para especificar o título da seção. Ela é usada apenas antes do modelo (se usado) ser criado inicialmente, já que o título definido no arquivo de modelo sobrescreve este. Também, se for usado o comentário SECTION nos fontes, isso está obsoleto.
Você pode agrupar itens na seção usando a tag <SUBSECTION>. Atualmente, ela retorna uma linha em branco entre as subseções na seção de sinopse. Você também pode usar <SUBSECTION Standard> para declarações padrão do GObject (ex.: as funções como g_object_get_type e macros como G_OBJECT(), G_IS_OBJECT() etc.). Atualmente, estas são deixadas fora da documentação. Você também pode usar <SUBSECTION Private> para declarações privadas que não serão retornadas (é uma forma prática de evitar mensagens de aviso sobre declarações não usadas). Se sua biblioteca contém tipos privados que você não deseja que apareçam na hierarquia do objeto e a linha de classes implementadas ou exigidas, adicione-as a uma subseção privada. Se você colocaria o GObject e GObjectClass como structs numa seção padrão ou pública depende se há entradas públicas (variáveis, vmethods).
Você também pode usar <INCLUDE> ... </INCLUDE> para especificar os arquivos #include que são mostrados nas seções de sinopse. Ela contém uma lista separada por vírgula de arquivos #include, sem os sinais de maior que e menor que. Se você define-a fora de quaisquer seções, ela age para todas as seções até o fim do arquivo. Se você define-a em uma seção, ela só vai se aplicar àquela seção.