વધારાની ફાઇલોને ભરી રહ્યા છે
There are a couple of extra files, that need to be maintained along with the inline source code comments: <package>.types, <package>-docs.xml (in the past .sgml), <package>-sections.txt.

ફાઇલોનાં પ્રકારોને સુધારી રહ્યા છે
If your library or application includes GObjects, you want their signals, arguments/parameters and position in the hierarchy to be shown in the documentation. All you need to do, is to list the xxx_get_type functions together with their include inside the <package>.types file.

Example types file snippet

#include <gtk/gtk.h>

gtk_accel_label_get_type
gtk_adjustment_get_type
gtk_alignment_get_type
gtk_arrow_get_type

જ્યાં સુધી GTK-Doc 1.8 gtkdoc-scan એ તમારા માટે આ યાદી ઉત્પન્ન કરી શકે, Makefile.am માં SCAN_OPTIONS માટે "--rebuild-types" ને ખાલી ઉમેરો. જો તમે આ હેતુ થી વાપરો તો તમારે ફાઇલનાં પ્રકારોની યાદી કરવી જોઇએ નહિ અથવા આવૃત્તિ નિયંત્રણ હેઠળ તે હોવુ જોઇએ નહિં.

મુખ્ય દસ્તાવેજને સુધારી રહ્યા છે
GTK-Doc produces documentation in DocBook SGML/XML. When processing the inline source comments, the GTK-Doc tools generate one documentation page per class or module as a separate file. The master document includes them and place them in an order.
While GTK-Doc creates a template master document for you, later runs will not touch it again. This means that one can freely structure the documentation. That includes grouping pages and adding extra pages. GTK-Doc has now a test suite, where also the master-document is recreated from scratch. Its a good idea to look at this from time to time to see if there are some new goodies introduced there.
Do not create tutorials as extra documents. Just write extra chapters. The benefit of directly embedding the tutorial for your library into the API documentation is that it is easy to link for the tutorial to symbol documentation. Apart chances are higher that the tutorial gets updates along with the library.
So what are the things to change inside the master document? For a start is only a little. There are some placeholders (text in square brackets) there which you should take care of.

મુખ્ય દસ્તાવેજ મથાળુ

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

In addition a few option elements are created in commented form. You can review these and enable them as you like.

Optional part in the master document

  <!-- enable this when you use gobject introspection annotations
  <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include>
  -->

Finally you need to add new section whenever you introduce one. The gtkdoc-check tool will remind you of newly generated xml files that are not yet included into the doc.

Including generated sections

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

વિભાગ ફાઇલને સુધારી રહ્યા છે
The section file is used to organise the documentation output by GTK-Doc. Here one specifies which symbol belongs to which module or class and control the visibility (public or private).
The section file is a plain text file with tags delimiting sections. Blank lines are ignored and lines starting with a '#' are treated as comment lines.
While the tags make the file look like xml, it is not. Please do not close tags like <SUBSECTION>.

Including generated sections

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

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

The <FILE> ... </FILE> tag is used to specify the file name, without any suffix. For example, using '<FILE>gnome-config</FILE>' will result in the section declarations being output in the template file tmpl/gnome-config.sgml, which will be converted into the DocBook XML file xml/gnome-config.sgml or the DocBook XML file xml/gnome-config.xml. (The name of the HTML file is based on the module name and the section title, or for GObjects it is based on the GObjects class name converted to lower case).
The <TITLE> ... </TITLE> tag is used to specify the title of the section. It is only useful before the templates (if used) are initially created, since the title set in the template file overrides this. Also if one uses SECTION comment in the sources, this is obsolete.
You can group items in the section by using the <SUBSECTION> tag. Currently it outputs a blank line between subsections in the synopsis section. You can also use <SUBSECTION Standard> for standard GObject declarations (e.g. the functions like g_object_get_type and macros like G_OBJECT(), G_IS_OBJECT() etc.). Currently these are left out of the documentation. You can also use <SUBSECTION Private> for private declarations which will not be output (it is a handy way to avoid warning messages about unused declarations). If your library contains private types which you don't want to appear in the object hierarchy and the list of implemented or required interfaces, add them to a Private subsection. Whether you would place GObject and GObjectClass like structs in public or Standard section depends if they have public entries (variables, vmethods).
You can also use <INCLUDE> ... </INCLUDE> to specify the #include files which are shown in the synopsis sections. It contains a comma-separate list of #include files, without the angle brackets. If you set it outside of any sections, it acts for all sections until the end of the file. If you set it within a section, it only applies to that section.