adding files for pdflatex support

[wxWidgets.git] / docs / tech / tn0003.txt

                     Adding wxWidgets class documentation
                     ====================================

This note is aimed at people wishing to add documentation for a
class to either the main wxWidgets manual, or to their own
manual.

wxWidgets uses Doxygen to process header input files with embedded
documentation in the form of C++ comments and output in HTML, and XML
(Doxygen itself can also output Latex, manpages, RTF, PDF etc).
See http://www.doxygen.org for more info about Doxygen.

If you want to add documentation of a new class/function to the 
existing manual in docs/doxygen, you need to create a new .h file,
e.g. myclass.h, under the interface folder, which contains the public
interface of the new class/function in C++ syntax.
The documentation can then be added in form of Doxygen comments to
the header file.

You may also want to write a separate topic file,
e.g. docs/doxygen/overviews/myclass.h, and add the entry to
docs/doxygen/mainpages/topics.h.

If applicable, also add an entry to one of the docs/doxygen/mainpages/cat_*.h
files.

You can generate a first raw version of myclass.h simply taking its
"real" header and removing all the private and protected sections and
in general removing everything the user "shouldn't know": i.e. all things
which are implementation details.


Running Doxygen
===============

First, make sure you have a recent version of Doxygen installed in your system.

For HTML:

  1) cd wxWidgets/docs/doxygen
  2) run ./regen.sh [Unix]    or   regen.bat [Windows]

[TODO: istructions for generation of other formats]


Important Dos and Don'ts
========================

DO:

- Doxygen supports both commands in the form \command and @command;
  all wxWidgets documentation uses the @command form.
  Follow strictly this rule.

- strive to use dedicated Doxygen commands for e.g. notes, lists,
  sections, etc. The "Special commands" page:
    http://www.stack.nl/~dimitri/doxygen/commands.html
  is your friend!
  It's also very important to make a consistent use of the ALIASES
  defined by wxWidgets' Doxyfile. Open that file for more info.

- when you write true, false and NULL with their C++ semantic meaning,
  then use the @true, @false and @NULL commands.

- separe different paragraphs with an empty comment line.
  This is important otherwise Doxygen puts everything in the same
  paragraph making the result less readable.

- leave a blank comment line between a @section, @subsection, @page
  and the next paragraph.

- test your changes, both reading the generated HTML docs and by looking
  at the "doxygen.log" file produced (which will warn you about any
  eventual mistake found in the comments).

- quote all the following characters prefixing them with a "@" char:

         @  $  \  &  <  >  #  %

  unless they appear inside a @code or @verbatim section
  (you can also use HTML-style escaping, e.g. &amp; rather than @ escaping)

- when using a Doxygen alias like @itemdef{}, you need to escape the
  comma characters which appear on the first argument, otherwise Doxygen
  will interpret them as the marker of the end of the first argument and
  the beginning of the second argument's text.

  E.g. if you want to define the item "wxEVT_MACRO(id, func)" you need to
       write:
            @itemdef{wxEVT_MACRO(id\, func), This is the description of the macro}

  Also note that you need to escape only the commas of the first argument's text;
  second argument can have up to 10 commas unescaped (see the Doxyfile for the
  trick used to implement this).

DON'T:

- use jargon, such as 'gonna', or omit the definite article.
  The manual is intended to be a fluent, English document and
  not a collection of rough notes.

- use non-alphanumeric characters in link anchors.

- use Doxygen @b @c @e commands when referring to more than a single word;
  in that case you need to use the <b>...</b>, <tt>...</tt>, <em>...</em>
  HTML-style tags instead

- use HTML style tags for creation of tables or lists.
  Use wx aliases instead like @beginTable, @row2col, @row3col, @endTable and
  @beginDefList, @itemdef, @endDefList, etc.
  See the Doxyfile for more info.

- use # character for linking; use either the @ref command (to refer to topic
  overviews, for example) or the () suffix (to refer to function members of the
  same class you're documenting), or the :: operator (to refer to functions
  of classes different from the one you're documenting).
  Other entitites like global functions, global instances or class names are
  auto-linked by Doxygen without the need of any explicit command.


Documentation comment for a class
=================================

Start off with:

/**
 * @class wxMyClass
 * @wxheader{myclass.h}
 *
 * ...here goes the description... 
 *
 * @beginEventTable
 * @event{EVT_SOME_EVENT(id, func)}:
 *        Description for EVT_SOME_EVENT.
 * @endEventTable
 *
 * @beginStyleTable
 * @style{wxSOME_STYLE}:
 *        Description for wxSOME_STYLE.
 * ...
 * @endStyleTable
 *
 * @beginExtraStyleTable
 * @style{wxSOME_EXTRA_STYLE}:
 *        Description for wxSOME_EXTRA_STYLE.
 * ...
 * @endExtraStyleTable
 *
 * @library{wxbase}
 * @stdobjects
 * ...here goes the list of predefined instances...
 *
 * @seealso
 * ...here goes the see-also list...
 * you can make references to topic overviews or other
 * manual pages using the @ref command
 */

Note that the events, styles and extra-styles tables as
well as @stdobjects and @seealso lists are optional.

Also note that you shouldn't use the Doxygen builtin @sa command
for the see-also list but rather the wxWidgets' alias @seealso
in this case.


Documentation comment for a function
====================================

Start off with:

/**
 * ...here goes the description of the function....
 *
 * @param param1
 * ...here goes the description for the first parameter of this function
 * @param param2
 * ...here goes the description for the second parameter of this function
 * ...
 *
 * @return
 * ...here goes the description of what the function returns...
 *
 * @note ...here go any eventual notes about this function...
 *
 * @remarks ...here go any eventual remarks about this function...
 *
 * @sa ...here goes the see-also list...
 */

Note that the @return, @note, @remarks, @sa commands are optional.

Also note that unlike for class' description, you should use the doxygen
builtin @sa command here for see-also lists.

The @param command has an optional attribute specifying the direction of 
the attribute. Possible values are "in" and "out". E.g.

/**
 * Copies bytes from a source memory area to a destination memory area,
 * where both areas may not overlap.
 * @param[out]     dest   The memory area to copy to.
 * @param[in]      src    The memory area to copy from.
 * @param[in]      n      The number of bytes to copy.
 * @param[in,out]  pmisc  Used both as input and as output.
 */
void func(void *dest, const void *src, size_t n, void *pmisc);


Documentation comment for a topic overview
==========================================

Topic overviews are stored inside the docs/doxygen/overviews folder
and are completely placed inside a single comment block in the form of:

/*!

 @page overview_tname wxSomeStuff overview

 This page provides an overview of the wxSomeStuff and related classes.
 ....

 @li @ref overview_tname_intro
 @li @ref overview_tname_details
 ...

 <hr>


 @section overview_tname_intro Introduction

 ...here goes the introduction to this topic...


 @section overview_tname_details Details

 ...here go the details to this topic...

*/

Note that there is a convention in the anchor link names.
Doxygen in fact requires that for each @page, @section, @subsection, etc tag, 
there is a corresponding link anchor.

The following conventions are used in wxWidgets doxygen comments:

1) all "main" pages of the manual (those which are placed in docs/doxygen/mainpages) 
   have link anchors which begin with "page_"

2) all topic overviews (those which are placed in docs/doxygen/overviews) have link 
   anchors which begin with "overview_"

3) all @section, @subsection, @subsubsection tags should have as link anchor name
   the name of the parent section plus a specific word separed with an underscore; e.g.:

/*!

 @page overview_tname wxSomeStuff overview

 @section overview_tname_intro Introduction
  @subsection overview_tname_intro_firstpart First part
  @subsection overview_tname_intro_secondpart Second part
   @subsubsection overview_tname_intro_secondpart_sub Second part subsection
  @subsection overview_tname_intro_thirdpart Third part

 @section overview_tname_details Details
 ...

*/


=== EOF ===

Author: FM (under the lines of the previous technote about tex2rtf)
Version: $Id$