Release-1.2.15-20020430

3 files changed, 248 insertions, 98 deletions

diff --git a/doc/docblocks.doc b/doc/docblocks.doc
index 49a2f5f..9cb89e0 100644
--- a/doc/docblocks.doc
+++ b/doc/docblocks.doc
@@ -18,34 +18,154 @@
 
 \subsection specialblock Special documentation blocks
 
-The following types of special documentation blocks are supported by doxygen:
-<ul>
-<li>The Qt style, where special documentation blocks look like:
+A special documentation block is a C or C++ comment block with some 
+additional markings, so doxygen knows it is a piece of documentation that
+needs to end up in the generated documentation. 
+
+For each code item there are two types of descriptions, which together
+form the documentation: a \e brief description and \e detailed
+description, both are optional. 
+Having more than one brief or detailed description however, is 
+not allowed. 
+
+As the name suggest, a brief description is
+a short one-liner, whereas the detailed description provides longer, 
+more detailed documentation.
+
+There are several ways to mark a comment block as a detailed description:
+<ol>
+<li> You can use the JavaDoc style, which consist of a C-style comment
+block starting with two *'s, like this:
+
+\verbatim
+/**
+ * ... text ...
+ */
+\endverbatim
+
+<li> or you can use the Qt style and add an exclamation mark (!) 
+after the opening of a C-style comment block, as shown in this example:
+
 \verbatim
 /*!
-  ... text ...
+ * ... text ...
+ */
+\endverbatim
+
+In both cases the intermediate *'s are optional, so
+
+\verbatim
+/*!
+ ... text ...
 */
-\endverbatim and the one line version:
+\endverbatim
+
+is also valid.
+
+<li> A third alternative is to use a block of at least two C++ comment 
+lines, where the first starts with an additional slash or an 
+exclamation mark. Here are examples of the two cases:
+
+\verbatim
+///
+// ... text ...
+//
+\endverbatim
+
+or
+
 \verbatim
-//! ... one line of text ...
+//!
+// ... text ...
+//
 \endverbatim
-<li>The JavaDoc style, where special documentation blocks look like:
+
+<li>
+
+One could also repeat the special markers for each line as shown in
+the following examples:
+
 \verbatim
-/**
- * ... text ...
+/// 
+/// ... text ....
+///
+\endverbatim
+
+or 
+
+\verbatim
+//!
+//! ... text ...
+//!
+\endverbatim
+
+</ol>
+
+For the brief description there are also several posibilities:
+<ol>
+<li>One could use the \ref cmdbrief "\brief" command with one of the 
+above comment blocks. This command ends at the end of a paragraph, 
+so the detailed description follows after an empty line.
+
+Here is an example:
+
+\verbatim
+/*! \brief Brief description.
+ *         Brief description continued.
+ *
+ *  Detailed description starts here.
  */
-\endverbatim and the one line version:
+\endverbatim
+
+<li>If \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" is set to YES in the configuration file, 
+    then using JavaDoc style comment
+    blocks will automatically start a brief description which ends at the
+    first dot. Here is an example:
+
 \verbatim
-/// ... one line of text ...
+/** Brief description which ends at this dot. Details follow
+ *  here.
+ */
 \endverbatim
-</ul>
 
-Doxygen only allows one brief and one detailed description. If there is
-one brief description before a declaration and one before a
-definition, only the one before the \e declaration will be used. If
-the same situation occurs for a detailed description,
-the one before the \e definition is preferred and the one before the
-declaration will be ignored.
+<li>A third option is to use a special C++ style comment which does not 
+    span more than one line. Here are two examples:
+\verbatim
+/// Brief description.
+/** Detailed description. */
+\endverbatim
+
+or
+
+\verbatim
+//! Brief descripion.
+
+//! Detailed description 
+//! starts here.
+\endverbatim
+
+Note the blank line in the last example, which is required to separate the 
+brief description from the block containing the detailed description.
+
+</ol>
+
+As you can see doxygen is quite flexible. The following however is
+not legal
+
+\verbatim
+//! Brief description, which is
+//! really a detailed description since it spans multiple lines.
+/*! Oops, another detailed description!
+ */
+\endverbatim
+
+because doxygen only allows one brief and one detailed description. 
+
+Furthermore, if there is one brief description before a declaration 
+and one before a definition of a code item, only the one before 
+the \e declaration will be used. If the same situation occurs for a 
+detailed description, the one before the \e definition is preferred 
+and the one before the declaration will be ignored.
 
 Here is an example of a documented piece of C++ code using the Qt style:
 \verbinclude qtstyle.cpp
@@ -54,10 +174,10 @@ Here is an example of a documented piece of C++ code using the Qt style:
  for the corresponding HTML documentation that is generated by doxygen.
  \endhtmlonly
 
-The one-line comments should contain a brief description, 
+The one-line comments contain a brief description, 
 whereas the multi-line comment blocks contain a more detailed description.
-Note that consecutive one-line comments are merged together in one brief 
-description. The brief descriptions are included in the member overview of a 
+
+The brief descriptions are included in the member overview of a 
 class, namespace or file and are printed using a small italic font 
 (this description can be hidden by setting 
 \ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" to \c NO in 
@@ -95,25 +215,82 @@ implementer of the members more direct access to the documentation.
 As a compromise the brief description could be placed before the
 declaration and the detailed description before the member definition.
 
-\par Note:
-Each entity can only have \e one brief and \e one detailed description. If you
-specify more than one comment block of the same type, only one will be used,
-and all others are ignored!
+\subsection memberdoc Documenting members afterwards
+
+If you want to document the members of a file, struct, union, class, or enum,
+and you want to put the documentation for these members inside the compound,
+it is sometimes desired to place the documentation block after the member 
+instead of before. For this purpose you should put an additional \< marker
+in the comment block.
+
+Here are some examples:
+\verbatim
+int var; /*!< Detailed description after the member */
+\endverbatim
+This block can be used to put a Qt style detailed 
+documentation block \e after a member. Other ways to do the
+same are:
+\verbatim
+int var; /**< Detailed description after the member */
+\endverbatim
+or 
+\verbatim
+int var; //!< Detailed description after the member
+         //!< 
+\endverbatim
+or 
+\verbatim
+int var; ///< Detailed description after the member
+         ///< 
+\endverbatim
+
+Most often one only wants to put a brief description after a member.
+This is done as follows:
+\verbatim
+int var; //!< Brief description after the member
+\endverbatim
+or
+\verbatim
+int var; ///< Brief description after the member
+\endverbatim
+
+Note that these blocks have the same structure and meaning as the 
+special comment blocks in the previous section 
+only the \< indicates that the member is 
+located in front of the block instead of after the block.
+
+Here is an example of the use of these comment blocks:
+\verbinclude afterdoc.h
+ \htmlonly
+ Click <a href="$(DOXYGEN_DOCDIR)/examples/afterdoc/html/class_test.html">here</a>
+ for the corresponding HTML documentation that is generated by doxygen.
+ \endhtmlonly
+
+\warning These blocks can only be used to document \e members and \e parameters.
+         They cannot be used to document files, classes, unions, structs,
+         groups, namespaces and enums themselves. Furthermore, the structural 
+         commands mentioned in the next section 
+         (like <code>\\class</code>) are ignored inside these comment blocks.
 
-\subsection structuralcommands Structural commands
+\subsection structuralcommands Documentation at other places
 
 So far we have assumed that the documentation blocks are always located in 
 front of the declaration or definition of a file, class or namespace or in
-front of one of its members. 
-Although this is often comfortable, it may sometimes be better to put the 
-documentation somewhere else. For some types of documentation blocks (like file
-documentation) this is even required. Doxygen allows you to put your
-documentation blocks practically anywhere (the exception is inside the body 
-of a function or inside a normal C style comment block), as long as you put a 
-structural command inside the documentation block.
+front or after one of its members. 
+Although this is often comfortable, there may sometimes be reasons to put the 
+documentation somewhere else. For documenting a file this is even 
+required since there is no such thing as "in front of a file". 
+Doxygen allows you to put your documentation blocks practically 
+anywhere (the exception is inside the body of a function or inside a 
+normal C style comment block). 
+
+The price you pay for not putting the
+documentation block before (or after) an item is the need to put a  
+structural command inside the documentation block, which leads to some
+duplication of information.
 
 Structural commands (like all other commands) start with a backslash 
-(<tt>\\</tt>), or an at-sign (<tt>\@</tt>) in JavaDoc style, 
+(<tt>\\</tt>), or an at-sign (<tt>\@</tt>) if you prefer JavaDoc style, 
 followed by a command name and one or more parameters.
 For instance, if you want to document the class \c Test in the example
 above, you could have also put the following documentation block somewhere
@@ -138,16 +315,17 @@ Other structural commands are:
 <li>\c \def to document a \#define.
 <li>\c \file to document a file.
 <li>\c \namespace to document a namespace.
+<li>\c \package to document a Java package.
+<li>\c \interface to document an IDL interface.
 </ul>
-See section \ref commands for detailed information about these and other 
-commands. Note that the documentation block belonging to a file 
-should always contain a structural command.
+See section \ref commands for detailed information about these and many other 
+commands. 
 
 To document a member of a C++ class, you must also document the class 
-itself. The same holds for namespaces. To document a global C function, typedef, 
-enum or preprocessor definition you must first document the file that 
-contains it (usually this will be a header file, because that file contains 
-the information that is exported to other source files).
+itself. The same holds for namespaces. To document a global C function, 
+typedef, enum or preprocessor definition you must first document the file 
+that contains it (usually this will be a header file, because that file 
+contains the information that is exported to other source files).
 
 Let's repeat that, because it is often overlooked:
 to document global objects (functions, typedefs, enum, macros, etc), you
@@ -163,55 +341,15 @@ using structural commands:
  for the corresponding HTML documentation that is generated by doxygen.
  \endhtmlonly
 
-\par Note:
-  Because each comment block in the example above contains a structural command, all
-  the comment blocks could be moved to another location or input file 
-  (the source file for instance), without affecting the generated 
-  documentation. The disadvantage of this approach is that prototypes are
-  duplicated, so all changes have to be made twice!
-
-\subsection memberdoc Documenting compound members.
-
-If you want to document the members of a file, struct, union, class, or enum,
-and you want to put the documentation for these members inside the compound,
-it is sometimes desired to place the documentation block after the member 
-instead of before. For this purpose doxygen has the following 
-additional comment blocks:
-\verbatim
-/*!< ... */
-\endverbatim
-This block can be used to put a Qt style detailed 
-documentation block after a member.
-The one line brief description looks as follows:
-\verbatim
-//!< ...
-\endverbatim
-There are also JavaDoc versions for detailed documentation:
-\verbatim
-/**< ... */
-\endverbatim
-(where the first sentence is the brief description 
-if \c JAVADOC_AUTOBRIEF is set to \c YES)
-and there is a separate brief description as well:
-\verbatim
-///< ... 
-\endverbatim
-Note that these blocks have the same structure and meaning as the 
-special comment blocks above only the \< indicates that the member is 
-located in front of the block instead of after the block.
-
-Here is an example of the use of these comment blocks:
-\verbinclude afterdoc.h
- \htmlonly
- Click <a href="$(DOXYGEN_DOCDIR)/examples/afterdoc/html/class_test.html">here</a>
- for the corresponding HTML documentation that is generated by doxygen.
- \endhtmlonly
-
-\warning These blocks can only be used to document \e members and \e parameters.
-         They cannot be used to document files, classes, unions, structs,
-         groups, namespaces and enums themselves. Furthermore, the structural 
-         commands mentioned in the previous section 
-         (like <code>\\class</code>) are ignored inside these comment blocks.
+ Because each comment block in the example above contains a structural command, all
+ the comment blocks could be moved to another location or input file 
+ (the source file for instance), without affecting the generated 
+ documentation. The disadvantage of this approach is that prototypes are
+ duplicated, so all changes have to be made twice! Because of this you
+ should first consider if this is really needed, and avoid structural
+ commands if possible. I often receive examples that contain \\fn command
+ in comment blocks which are place in front of a function. This is clearly
+ a case where the \\fn command is redundant and will only lead to problems.
 
 \htmlonly
 Go to the <a href="lists.html">next</a> section or return to the
diff --git a/doc/language.doc b/doc/language.doc
index 10a7082..58a92ec 100644
--- a/doc/language.doc
+++ b/doc/language.doc
@@ -25,13 +25,14 @@ Doxygen has built-in support for multiple languages. This means
 that the text fragments that doxygen generates can be produced in
 languages other than English (the default) at configuration time.
 
-Currently (version 1.2.14-20020317), 25 languages 
+Currently (version 1.2.15-20020421), 26 languages 
 are supported (sorted alphabetically): 
-Brazilian Portuguese, Chinese, Croatian, Czech, Danish, 
-Dutch, English, Finnish, French, German, 
-Greek, Hungarian, Italian, Japanese, Korean, 
-Norwegian, Polish, Portuguese, Romanian, Russian, 
-Slovak, Slovene, Spanish, Swedish, and Ukrainian.
+Brazilian Portuguese, Chinese, Chinesetraditional, Croatian, Czech, 
+Danish, Dutch, English, Finnish, French, 
+German, Greek, Hungarian, Italian, Japanese, 
+Korean, Norwegian, Polish, Portuguese, Romanian, 
+Russian, Slovak, Slovene, Spanish, Swedish, 
+and Ukrainian.
 
 The table of information related to the supported languages follows.
 It is sorted by language alphabetically.  The <b>Status</b> column
@@ -63,6 +64,12 @@ when the translator was updated.
       <TD>1.2.13</TD>
   </TR>
   <TR BGCOLOR="#ffffff">
+      <TD>Chinesetraditional</TD>  
+      <TD>Gary Lee</TD>
+      <TD>garylee@NOSPAM.ecosine.com.tw</TD>
+      <TD>up-to-date</TD>
+  </TR>
+  <TR BGCOLOR="#ffffff">
       <TD>Croatian</TD>  
       <TD>Boris Bralo</TD>
       <TD>boris.bralo@NOSPAM.zg.tel.hr</TD>
@@ -180,7 +187,7 @@ when the translator was updated.
       <TD>Slovene</TD>  
       <TD>Matjaz Ostroversnik</TD>
       <TD>matjaz.ostroversnik@NOSPAM.zrs-tk.si</TD>
-      <TD>1.2.13</TD>
+      <TD>up-to-date</TD>
   </TR>
   <TR BGCOLOR="#ffffff">
       <TD>Spanish</TD>  
@@ -216,6 +223,8 @@ when the translator was updated.
   Chinese & Wei Liu & {\tt liuwei@asiainfo.com} & 1.2.13 \\
    & Wang Weihan & {\tt wangweihan@capinfo.com.cn} &  \\
   \hline
+  Chinesetraditional & Gary Lee & {\tt garylee@ecosine.com.tw} & up-to-date \\
+  \hline
   Croatian & Boris Bralo & {\tt boris.bralo@zg.tel.hr} & up-to-date \\
   \hline
   Czech & Petr P\v{r}ikryl & {\tt prikrylp@skil.cz} & up-to-date \\
@@ -257,7 +266,7 @@ when the translator was updated.
   \hline
   Slovak & Stanislav Kudl\'{a}\v{c} & {\tt skudlac@pobox.sk} & 1.2.13 \\
   \hline
-  Slovene & Matjaz Ostroversnik & {\tt matjaz.ostroversnik@zrs-tk.si} & 1.2.13 \\
+  Slovene & Matjaz Ostroversnik & {\tt matjaz.ostroversnik@zrs-tk.si} & up-to-date \\
   \hline
   Spanish & Francisco Oltra Thennet & {\tt foltra@puc.cl} & 1.2.7 \\
   \hline
diff --git a/doc/maintainers.txt b/doc/maintainers.txt
index 488573d..5f2ec0c 100644
--- a/doc/maintainers.txt
+++ b/doc/maintainers.txt
@@ -8,6 +8,9 @@ Chinese
 Wei Liu: liuwei@asiainfo.com
 Wang Weihan: wangweihan@capinfo.com.cn
 
+ChineseTraditional
+Gary Lee: garylee@ecosine.com.tw
+
 Croatian
 Boris Bralo: boris.bralo@zg.tel.hr