doxygen-develop — List for discussing new features, submitting patches, etc.

Re: [Doxygen-develop] XML missing field (plus patch)

[Chris C. <do...@ke...>]

On Sat, Jun 05, 2004 at 05:14:49PM +0200, Dimitri van Heesch wrote:

> On Fri, Jun 04, 2004 at 08:32:21PM +0100, Chris Croughton wrote:
> > XML output has a field missing.  If you have a group round a series of
> > functions:
> 
> No, it's the same parser, but you should use writeXMLDocBlock() to invoke it.

Ah, I think I have it.  I'm not sure about some of the parameters,
specifically the file name and line number (setting the MemberDef* to
null seems to be OK).  I'm doing:

    t << "      <documentation>";
    writeXMLDocBlock(t,d->docFile(),d->docLine(),d,0,documentation);
    t << "</documentation>" << endl;

since a MemberList doesn't seem to have a docFil() or docLine() function
for the documention of a user section, and when an error occurs that
gives the correct file name but the wrong line number (relative to the
start of the comment block rather than to the file).  'd' is the pointer
to the Definition passed into generateXMLSection().

Question: should the header output also be using writeXMLDocBlock() and
not convertToXML() as at present?  I suspect that it's valid to have
markup in there...

Chris C

Re: [Doxygen-develop] XML missing field (plus patch)

[Dimitri v. H. <di...@st...>]

On Fri, Jun 04, 2004 at 08:32:21PM +0100, Chris Croughton wrote:
> XML output has a field missing.  If you have a group round a series of
> functions:
> 

Thanks, I'll fix this using your patch.

> However, it's not a total fix, because markup inside the documentation
> is not interpreted, so having something like:
> 
>   /**
>    * @name My group.
>    * This is a \b description of the group.
>    */
> 
> will result in
> 
>   <documentation>This is a \b description of the group. </documentation>
> 
> instead of
> 
>   <documentation>This is a <b>description<\b> of the group. </documentation>
> 
> as it would elsewhere (and of course other markup as well).  I don't
> understand the parsing well enough yet to work out how to fix that, the
> HTML parsing seems to be very different from that for XML.
> 

No, it's the same parser, but you should use writeXMLDocBlock() to invoke it.

Regards,
  Dimitri

Re: [Doxygen-develop] Problem with enumvalueType in XML schema

[Dimitri v. H. <di...@st...>]

On Thu, May 27, 2004 at 03:14:43PM -0700, Pau...@no... wrote:
> I have been working with XML SPY, and if I generate XML output from Doxygen and then load a class XML file in SPY, it cannot validate it if enumvalue entries are present with initializer elements. What I find is that the schema defines the content of the enumvalue to be a sequence of the elements:
> 
> name
> briefdescription
> detaileddescription
> initializer
> 
> but the code puts the initializer element after the name and before the briefdescription, which causes validation to fail, because the elements must be in the same order as in the schema (I think) if they are defined at all. Should the schema be changed to put the initializer element before briefdescription?
> 
> I appreciate it if anyone can confirm this for me or tell me if my understanding is incorrect.

Yes, this is a bug and the schema will be changed to reflect the correct order.

> 
> Also, I noticed there was a change posted about adding an option to Doxygen to create a single XML output file if desired (details below). Is there any reason why this cannot be integrated into Doxygen? Given the nature of XML tools, I frequently find I want to do just this to make further processing simpler.

Doxygen already generates a XSLT file to combine the output files. For any
large project the XML file that doxygen generates becomes so huge no DOM 
based XML processing tools can handle it, which was the main reason for 
me to split the output into multiple files.

Regards,
  Dimitri

[Doxygen-develop] XML missing field (plus patch)

[Chris C. <do...@ke...>]

XML output has a field missing.  If you have a group round a series of
functions:

  /**
   * @name My group.
   * This is a description of the group.
   */
  //@{
  /// Function.
  void fred();
  /// Another function.
  void bill();
  //@}

Then in all of the other formats the group is output with the
description.  In the XML output, however, the @name line is output as
<header>My group.</header> but the description is lost.

The attached patch corrects this, and adds an element <documentation> to
the <sectiondef> compound (kind="user-defined").

However, it's not a total fix, because markup inside the documentation
is not interpreted, so having something like:

  /**
   * @name My group.
   * This is a \b description of the group.
   */

will result in

  <documentation>This is a \b description of the group. </documentation>

instead of

  <documentation>This is a <b>description<\b> of the group. </documentation>

as it would elsewhere (and of course other markup as well).  I don't
understand the parsing well enough yet to work out how to fix that, the
HTML parsing seems to be very different from that for XML.

Chris C

[Doxygen-develop] [PATCH] - small fix for Russian translation

[Mikhail G. <bb...@ma...>]

Fixes grammar mistake and removes unneeded function.

Re: [Doxygen-develop] Backends, specifically Texinfo

[Chris C. <do...@ke...>]

On Sun, May 23, 2004 at 12:05:56AM -0400, Douglas Gregor wrote:

> ----- Original Message ----- 
> From: "Chris Croughton" <do...@ke...>
> >   Using XSLT on the XML output as a backend.
> >   Using any other XML backend processing.
> 
> We do both within the BoostBook format:
> 
>   http://www.boost.org/doc/html/boostbook.html

Which seems to be YANSF (yet another non-standard format).

> We use XSLT to transform Doxygen's XML output into our own XML format for
> representing C++ declarations with documentation. This new format (called
> BoostBook) can then be transformed into DocBook documentation (also via
> XSLT), and then we use Norman Walsh's stylesheets to generate HTML, PDF,
> etc. from the DocBook. One can see some BoostBook-formatted documentation
> here (although this didn't actually come through Doxygen):
> 
>   http://www.boost.org/doc/html/signals.reference.html

Yes, although what I want is something more like Doxygen's HTML and
Latex formats output in GNU/FSF standard Texinfo format (in particular,
that example doesn't seem to have parameter descriptions, which in my
experience are an important part of an API, I presume you can do that
with your format if you want to).

> At some point I'd like to propose that Doxygen's XML format keep more
> semantic information available, e.g., by representing overloaded functions
> in XML (using \overload)

As a Doxygen input directive in the source?  Can't you do that anyway
if you want it using an alias?  I suspect that getting Doxygen to
recognise overloaded functions itself would be more difficult (and
impossible in a generic case because it may not have some of the files
which define some of the overloaded functions).

> and providing appropriate nestings.

What nestings would those be?  Perhaps my code is insufficiently
complicated...

> Our Doxygen XML -> BoostBook XML stylesheet has to jump through quite
> a few hoops to rebuild this semantic info.

Hmm.  I did think that in some cases it would be necessary to build a
database before producing the output, because of references.

Chris C

Re: [Doxygen-develop] Backends, specifically Texinfo

[Douglas G. <gr...@cs...>]

----- Original Message ----- 
From: "Chris Croughton" <do...@ke...>
>   Using XSLT on the XML output as a backend.
>   Using any other XML backend processing.

We do both within the BoostBook format:

  http://www.boost.org/doc/html/boostbook.html

We use XSLT to transform Doxygen's XML output into our own XML format for
representing C++ declarations with documentation. This new format (called
BoostBook) can then be transformed into DocBook documentation (also via
XSLT), and then we use Norman Walsh's stylesheets to generate HTML, PDF,
etc. from the DocBook. One can see some BoostBook-formatted documentation
here (although this didn't actually come through Doxygen):

  http://www.boost.org/doc/html/signals.reference.html

At some point I'd like to propose that Doxygen's XML format keep more
semantic information available, e.g., by representing overloaded functions
in XML (using \overload) and providing appropriate nestings. Our Doxygen
XML -> BoostBook XML stylesheet has to jump through quite a few hoops to
rebuild this semantic info.

    Doug

[Doxygen-develop] ToDo item #10, @import / @region

[Chris C. <do...@ke...>]

Is anyone working on this item?  It's one I want as well, if I
understand it correctly (import text from a file with processing,
optionally from a specified region of the file).  As I understand it,
this would allow something like:

file.c:

  /**
    Standard function.
    @import param.doc
  */
  void func(int par, char *arg)
  {
  }

  /**
    Another function with hte same parameters.
    @import param.doc
  */
  void another(int par, char *arg)
  {
  }

param.doc:

  @param par   First parameter.
  @param arg   String argument.

Or for that matter re-using comments from the same file:

  /**
    Function with commaon parameters.
    @region StdFunc
    @param par   First parameter.
    @param arg   String argument.
    @endregion StdFunc
  */
  void func(int par, char *arg)
  {
  }

  /**
    Another function with the same parameters.
    @import file.c StdFunc
  */
  void another(int par, char *arg)
  {
  }

If someone is already working on it, would they like help or a tester?
If not I'll have a go (and would appreciate pointers where to start
looking in the source to add the commands and to change the input
stream).

Chris C

[Doxygen-develop] Backends, specifically Texinfo

[Chris C. <do...@ke...>]

I had a look in the wishlist (sorry, "to do" list) and couldn't find any
suggestion of producing Texinfo (as used by the GNU/FSF documentation)
output.  I'm less than no expert on Texinfo, but it would seem to me to
be compatible with the way Doxygen output is structured (a lot more
compatible than man pages, certainly).

I seem to remember some time ago that there was a proposal to produce a
common intermediate format, and then backends could use that.  XML would
seen to be a good candidate, and it seems that Doxygen's XML generation
is now quite complete and bug-free.  It has been suggested to me that
XSLT could then process that into whatever form is needed (but I know
next to nothing about XSLT either!).

My questions therefore are whether anyone is working on these areas,
specifically:

  Any Texinfo backend.
  Using XSLT on the XML output as a backend.
  Using any other XML backend processing.

Thanks to Dimitri and other contributors for the work so far.  Doxygen
is one of my "must have" useful programs...

Chris C

[Doxygen-develop] Improvements to member description

[David B. <dav...@ho...>]

I am new to this list, but not new to Doxygen. I recently upgraded to
Doxygen 1.3.7. I am running Doxygen on Windows to create HTML files, and
am also running HTMLHelp.

I like to new cascading style file, and I like the addition of the class
member descriptions in the class member summary at the top of a class
reference page. My improvement deals specifically with the member
description which I see listed as part of the public member functions.

The bug I see is that the HTMLHelp tool doesn't know how to handle the
"font-size: smaller" statements in the default cascading style sheet. As
a result, the size of the member descriptions are very large. I've also
noticed that Doxygen adds two <BR> tags after every description, so even
when I modify the a custom .cs file, I cannot properly control the
padding on the bottom of each description.

My suggested patch to htmlgen.cpp will accomplish two things:

1) For the mdescLeft and mdescRight styles, use a 14px font size instead
of "smaller", which the HTMLHelp and all browsers recognize.
2) Eliminate the second <BR> tag in the HTML output for the member
description, changed in the HtmlGenerator::endMemberDescription method.
3) Modify the padding of the mdescLeft and mdescRight styles to
accomplish the same thing that the extra <BR> did in the HTML.

These changes will accomplish the following for the end user:

1) HTMLHelp will properly size the member descriptions in the resulting
.chm file.
2) The end user has better control over the layout of the member
descriptions in a custom cascading style file.

Thank you,
David Baird


Index: htmlgen.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmlgen.cpp,v
retrieving revision 1.106
diff -r1.106 htmlgen.cpp
128c128
< "DIV.groupText { margin-left: 16px; font-style: italic; font-size:
smaller }\n"
---
> "DIV.groupText { margin-left: 16px; font-style: italic; font-size:
14px }\n"
182c182,183
< "	font-size: smaller;\n"
---
> "	padding: 0px 8px 4px 8px;\n"
> "	font-size: 14px;\n"
185d185
< "	padding-left: 8px;\n"
193c193,194
< "	font-size: smaller;\n"
---
> "	padding: 0px 8px 4px 8px;\n"
> "	font-size: 14px;\n"
196d196
< "	padding-left: 4px;\n"
202,203d201
< "	padding-bottom: 0px;\n"
< "	padding-right: 8px;\n"
225c223
< "	padding: 1px 0px 0px 8px;\n"
---
> "	padding: 1px 8px 0px 8px;\n"
909c907
<     t << "<br><br></td></tr>" << endl; 
---
>     t << "<br></td></tr>" << endl; 
913c911
<     t << "<br><br></dl>";
---
>     t << "<br></dl>";

[Doxygen-develop] Windows binaries available for Doxygen-1.3.7-20040517 in CVS

[Petr P. <Pr...@sk...>]

Hi,
  =20
If interested, you can download the doxygen binaries
compiled for MS Windows from
  =20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
  =20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release and looks like
doxygen_win32_2004mmdd.zip, where mm and dd is
month and day of releasing the version.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
  =20
Regards,
    Petr
=20
P.S. The translator report can be found in the file=20
     like tr2004mmdd.zip.
   =20
--=20
Petr Prikryl (prikrylp at skil dot cz)

Re: [Doxygen-develop] Adding a new config switch?

[Dimitri v. H. <di...@st...>]

On Mon, May 17, 2004 at 09:31:45AM -0700, Thomas Costa wrote:
> Quick question to make sure I don't miss anything.
> What files should I change so that a new config switch shows up in all 
> the right places (the GUI config app, the documentation, the binary)?

You need to add the option to src/config.l (you'll find the options at
the bottom of the file) and its documentation to doc/config.doc.

> I've got changes to htmlgen.cpp that conditionally use 
> 'style="white-space: no wrap"' instead of "nowrap" and I wanted to add 
> a HTML_USE_CSS_NOWRAP boolean config switch to control it.

In this case it may be better to send this as a non optional improvement ;)

Regards,
  Dimitri

[Doxygen-develop] Patch to Doxygen 1.3.7 for man file output

[Chris C. <do...@ke...>]

Hi all!

This patch corrects two bugs, both in man page output.

1)  Using \verbatim (and other commands turning off 'filling' of lines)
    caused the output to be left in that state for the rest of the file,
    due to having a .nf directive but no following .fi directive.

2)  If a function had only a brief description and no detailed
    description (for instance using the JAVADOC_AUTOBRIEF and
    REPEAT_BRIEF options) then following text, like the label
    'Parameters', would get put on the same line.  This was due to text
    output not setting the 'paragraph' flag.

Test code:

------------------------------------------------------------------------------
/**
  \file 1.cc
*/

/**
 * This is the main program.  No surprises there, then, but let's have some
 * text to fill things out a bit.  And another sentence for good luck.
 * @param argc the argument count
 * @param argv the argument pointer
 */
int main(int argc, char **argv)
{
  return 0;
}

/**
 * This has only a short description.
 * @param arg the argument
 */
void fred(int arg)
{
}

/**
 * A function to test verbatim output.  Let's have a bit of long description
 * first just to fill in the space...
\verbatim
        Lines to output "as is"
        with no filling
        not even cream.
\endverbatim
 * And now some text which needs to be filled with cream and
 * other sugary stuff which is bad for your teeth.  Not to mention
 * your waistline if you worry about such things...
 */
void function_verb(void)
{
}
------------------------------------------------------------------------------

Output without patch (just the detailed descriptions):

------------------------------------------------------------------------------
   int main (int argc, char ** argv)
       This is the main program. No surprises there, then, but let's have some
       text to fill things out a bit. And another sentence for good luck.

       Parameters:
           argc the argument count
           argv the argument pointer

   void fred (int arg)
       This has only a short description. Parameters:
           arg the argument

   void function_verb (void)
       A function to test verbatim output. Let's have a bit of long description
       first just to fill in the space...

               Lines to output "as is"
               with no filling
               not even cream.

       And now some text which needs to be filled with cream and other sugary stuff which is
 bad for your teeth. Not to mention your waistline if you worry about such things...
------------------------------------------------------------------------------

Output with patch (just the detailed descriptions):

------------------------------------------------------------------------------
   int main (int argc, char ** argv)
       This is the main program.

       No surprises there, then, but let's have some text to fill things out a
       bit. And another sentence for good luck.

       Parameters:
           argc the argument count
           argv the argument pointer

   void fred (int arg)
       This has only a short description.

       Parameters:
           arg the argument

   void function_verb (void)
       A function to test verbatim output.

       Let's have a bit of long description first just to fill in the space...

               Lines to output "as is"
               with no filling
               not even cream.

       And now some text which needs to be filled with cream and other sugary
       stuff which is bad for your teeth. Not to mention your waistline if you
       worry about such things...
------------------------------------------------------------------------------

Patch:
------------------------------------------------------------------------------
*** doxygen-1.3.7/src/mandocvisitor.cpp	Tue Apr 13 18:13:43 2004
--- src/mandocvisitor.cpp	Tue May 18 14:39:49 2004
***************
*** 167,172 ****
--- 167,173 ----
        {
          m_insidePre=FALSE;
          if (!m_firstCol) m_t << endl;
+         m_t << ".fi" << endl;
          m_t << ".PP" << endl;
          m_firstCol=TRUE;
        }
***************
*** 187,192 ****
--- 188,194 ----
        m_t << ".nf" << endl;
        parseCode(m_ci,s->context(),s->text().latin1(),s->isExample(),s->exampleFile());
        if (!m_firstCol) m_t << endl;
+       m_t << ".fi" << endl;
        m_t << ".PP" << endl;
        m_firstCol=TRUE;
        break;
***************
*** 196,201 ****
--- 198,204 ----
        m_t << ".nf" << endl;
        m_t << s->text();
        if (!m_firstCol) m_t << endl;
+       m_t << ".fi" << endl;
        m_t << ".PP" << endl;
        m_firstCol=TRUE;
        break;
***************
*** 230,235 ****
--- 233,239 ----
           FileDef fd( cfi.dirPath(), cfi.fileName() );
           parseCode(m_ci,inc->context(),inc->text().latin1(),inc->isExample(),inc->exampleFile(), &fd);
           if (!m_firstCol) m_t << endl;
+          m_t << ".fi" << endl;
           m_t << ".PP" << endl;
           m_firstCol=TRUE;
        }
***************
*** 240,245 ****
--- 244,250 ----
        m_t << ".nf" << endl;
        parseCode(m_ci,inc->context(),inc->text().latin1(),inc->isExample(),inc->exampleFile());
        if (!m_firstCol) m_t << endl;
+       m_t << ".fi" << endl;
        m_t << ".PP" << endl;
        m_firstCol=TRUE;
        break;
***************
*** 253,258 ****
--- 258,264 ----
        m_t << ".nf" << endl;
        m_t << inc->text();
        if (!m_firstCol) m_t << endl;
+       m_t << ".fi" << endl;
        m_t << ".PP" << endl;
        m_firstCol=TRUE;
        break;
***************
*** 287,292 ****
--- 293,299 ----
      if (!m_hide)
      {
        if (!m_firstCol) m_t << endl;
+       m_t << ".fi" << endl;
        m_t << ".PP" << endl;
        m_firstCol=TRUE;
      }
***************
*** 548,553 ****
--- 555,561 ----
  //{
  //  m_insidePre=FALSE;
  //  if (!m_firstCol) m_t << endl;
+ //  m_t << ".fi" << endl;
  //  m_t << ".PP" << endl;
  //  m_firstCol=TRUE;
  //}
*** doxygen-1.3.7/src/mangen.cpp	Wed Mar 24 20:36:05 2004
--- src/mangen.cpp	Tue May 18 14:33:34 2004
***************
*** 632,636 ****
--- 632,637 ----
    n->accept(visitor);
    delete visitor; 
    firstCol=FALSE;
+   paragraph = FALSE;
  }
  
------------------------------------------------------------------------------

[Doxygen-develop] Adding a new config switch?

[Thomas C. <oo...@ma...>]

Quick question to make sure I don't miss anything.
What files should I change so that a new config switch shows up in all 
the right places (the GUI config app, the documentation, the binary)?
I've got changes to htmlgen.cpp that conditionally use 
'style="white-space: no wrap"' instead of "nowrap" and I wanted to add 
a HTML_USE_CSS_NOWRAP boolean config switch to control it.
Cheers,
Tom Costa

[Doxygen-develop] Some bugs in russian translator.

[???????? ????????? ?????????? <ca...@cr...>]

	Hi doxygeners!
	Some bugs in russian translator. new translator_ru attached.
	Thanks to Alexander Borovsky.

[Doxygen-develop] Add a tab to RTF output

[Randall, L. <l-r...@ti...>]

I need to separate the parameter from the description with a tab in the =
RTF output, preferably by inserting a format string in the header file.  =
(All descriptions are drawn from the header files by placing "@fn =
functionName" in each C file function header.)  The RTF is processed by =
Word 2002 (Word XP).

=20

I have tried inserting \tab \\tab <file:///\\tab>  {\tab} and {\\tab} - =
with and without quotation marks.  The closest I can get is an output of =
"\tab" in the RTF file, which then can be searched and replaced with =
"^t" to produce a tab.

=20

Ideas??

=20

Format of header file:

/* =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D */

/**

* functionName() description for FunctionReturnType functionName().

* description continued =20

*

* @param *p     <description> *p

*

* @param a      <type> a=20

=20

Resultant output:

Parameters

        *p far* some pointer

=20

Desired output:

Parameters

        *p            far* some pointer

=20

Regards,

Larry Randall

=20

Re: [Doxygen-develop] @extends command to document that a c struct *extends* another

[Thomas C. <oo...@ma...>]

You support both techniques.

Add an @extends tag and also add a STRUCT_AUTOEXTEND_FIELD_NAME=xxx 
config option that will automagically apply the the @extend tag if the 
first field of a struct has the name "xxx". You might also want to 
allow the name to be specified as a prefix (i.e. your config says 
STRUCT_AUTOEXTEND_FIELD_NAME =_base and then it will trigger on 
_baseFoo or _baseBar as the first field name).

On May 6, 2004, at 8:28 AM, Stefan Kost wrote:

> hi dimitri,
>
> I wrote about this in an earlier poist (08.Dec.2003) but I guess it 
> got lost in
> the other issues. Here is it again:
>
> Wouldn't it be a good idea to have a @extends command (which should 
> not be used
> in C++/Java) so that I can document that a struct extends another in C.
>
> It is quite common in C to do:
>
> struct base;
>
> struct derived {
> 	struct base _base;
> 	...
> };
>
> I would like to see this reflected in the class hierarchy. Sugestion 
> is that
> doxygen either detects using a struct as a first member of a struct 
> and/or
> doxygen adds an @extends filed to the documentation of structs.
>
> What do you think about it? Has it a chance to be put onto the 
> wishlist ;-)
>
> ciao
>  Stefan
> -- 
>       \|/            Stefan Kost
>      <@ @>           private            business
> +-oOO-(_)-OOo------------------------------------------------------ - 
> - -  -   -
> |       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 
> 301166
> |      ///           04277 Leipzig      04251 Leipzig
> | __  ///            Germany            Germany
> | \\\///    Phone    +49341 2253538     +49341 30766101
> |  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
> |           WWW      www.sonicpulse.de  
> www.imn.htwk-leipzig.de/~kost/about.html
> ===-=-=--=---=---------------------------------- - - -  -    -
> <kost.vcf>

[Doxygen-develop] @extends command to document that a c struct *extends* another

[Stefan K. <ko...@im...>]

hi dimitri,

I wrote about this in an earlier poist (08.Dec.2003) but I guess it got lost in
the other issues. Here is it again:

Wouldn't it be a good idea to have a @extends command (which should not be used
in C++/Java) so that I can document that a struct extends another in C.

It is quite common in C to do:

struct base;

struct derived {
	struct base _base;
	...
};

I would like to see this reflected in the class hierarchy. Sugestion is that
doxygen either detects using a struct as a first member of a struct and/or
doxygen adds an @extends filed to the documentation of structs.

What do you think about it? Has it a chance to be put onto the wishlist ;-)

ciao
 Stefan
-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -

[Doxygen-develop] Windows binaries available for Doxygen-1.3.6-20040427 in CVS

[Petr P. <Pr...@sk...>]

Hi,
  =20
If interested, you can download the doxygen binaries
compiled for MS Windows from
  =20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
  =20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release and looks like
doxygen_win32_2004mmdd.zip, where mm and dd is
month and day of releasing the version.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
  =20
Regards,
    Petr
=20
P.S. The translator report can be found in the file=20
     like tr2004mmdd.zip.
   =20
--=20
Petr Prikryl (prikrylp at skil dot cz)

RE: [Doxygen-develop] Extracting more source struture in XML output

[Fred P. <j2...@ho...>]

Hi M. Paul Mackay and all,

>From: <Pau...@no...>
>To: <dox...@li...>
>Subject: [Doxygen-develop] Extracting more source struture in XML output
>Date: Mon, 26 Apr 2004 12:00:41 -0700
>

Well, I'm writing a software patch for Doyxgen to produce more "information"
on the SVG and XML back-end for
"Software Comprehension/Analysis/Visualization, testing, metrics and Reverse 
Engineering"

Currently, I'm working on tighter integration with Graphviz/Dot,
so it's used internally for speed reasons mostly and also to have Graphviz
generate more information on the SVG back-end.

Something like a web SVG/JS version of GraphViz/dotty for Windows.

>I have recently been looking at XML and the output Doxygen can produce. The 
>richness of information and versatility of what can be done with it is 
>impressive given the tools available for processing XML.
>
>Does anyone have any comments on the idea of Doxygen outputting more 
>information about the structure of the source code?

>I am thinking of a breakdown in terms of blocks, statements, declarations, 
>etc.

I'm also thinking in terms of block#, statement#, sub-statement#,
declared/defined/used statement/variable.

In our research group, we tried a lot of parsers.
Just look at IEEE/ACM papers, it's a common problem in our field.

The only ones that gives any "real" results are gcc/xml, doxygen and javac.

gcc/xml is too verbose.

javac is java only and doesn't have the easy "dynamic slicing" tracking 
advantage of C/C++.
There's no way of getting unique id for memory location of a variable.
In C/C++, just add TRACKING_USED( & variable );

doxygen seems to be a right balance, and fully support C/C++ and other 
languages.

>This could be used for more detailed metrics or a source browser for 
>example,

absolutely.

>but it also opens up more possibilities for independent tools that could 
>use the Doxygen XML output, e.g. code checking.

Maybe we can try to find out, if more people want to join or are looking for 
such features
and get specs and code out of it. That would be cool.

>This would enhance the current rich informational representation of the 
>code in XML.

The verboseness should be configurable from the configuration file 
absolutely.

You may also look at other standards like XMI, srcML, javaML, cppML, SVG, 
GXL, etc.

We tried in the past, javaML, but it didn't work quite nicely, 
/sun/tools/javac works much better.

Sincerely yours,
Fred.

_________________________________________________________________
MSN Premium includes powerful parental controls and get 2 months FREE*   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

[Doxygen-develop] Xml & page sections

[<ca...@cr...>]

	Hi, Dimitri and all!
	Reference to section( subsection, ... ) looks funnily in xml output:
------------------
/*! \page page1 A documentation page
  Leading text.
  \section sec An example section
  This page ...
*/

/*! \page page2 Another page
  Even more info. \ref sec
*/
------------------
	Doxygen create xml output for section
	<sect1 id=3D"sec"> ...</sect1>
		     !!!!
	But reference to section contain page name and looks like this:
	<ref refid=3D"page1_1sec" kindref=3D"member">
			!!!!!!!!!!

[Doxygen-develop] (no subject)

[Thomas C. <oo...@ma...>]

Is there some reason why \relates and \relatesalso cannot be used with 
a macro (i.e. inside a \def block)? I am willing to write the code and 
submit a patch if it is pretty straight forward.

[Doxygen-develop] Extracting more source struture in XML output

[<Pau...@no...>]

I have recently been looking at XML and the output Doxygen can produce. =
The richness of information and versatility of what can be done with it =
is impressive given the tools available for processing XML.

Does anyone have any comments on the idea of Doxygen outputting more =
information about the structure of the source code? I am thinking of a =
breakdown in terms of blocks, statements, declarations, etc. This could =
be used for more detailed metrics or a source browser for example, but =
it also opens up more possibilities for independent tools that could use =
the Doxygen XML output, e.g. code checking. This would enhance the =
current rich informational representation of the code in XML.

Paul Mackay

[Doxygen-develop] class graph images

[Jon S B. <js...@ha...>]

I've noticed that the MAX_DOT_GRAPH_WIDTH and _HEIGHTH parameters 
don't seem to work - when I get my graphs out, they are often quite 
large.

What I'd like to see is a smaller version of the graphs produced and 
placed as linked thumbnails on the page.  Is that possible?

Jon

[Doxygen-develop] Windows binaries available for Doxygen-1.3.6-20040413 in CVS

[Petr P. <Pr...@sk...>]

Hi,
  =20
If interested, you can download the doxygen binaries
compiled for MS Windows from
  =20
  http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/
  =20
This is the place where you should find also the next
releases.  The name of the archive is constructed=20
from the date of CVS release and looks like
doxygen_win32_2004mmdd.zip, where mm and dd is
month and day of releasing the version.
=20
The binaries are NOT created automatically, so it may
happen that some newer CVS sources were not compiled
because I am not present to do that or I forgot... ;)
  =20
Regards,
    Petr
=20
P.S. The translator report can be found in the file=20
     like tr2004mmdd.zip.
   =20
--=20
Petr Prikryl (prikrylp at skil dot cz)
=20

=20