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

[Doxygen-develop] test -- please ignore...

[Prikryl,Petr <PRI...@sk...>]

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

Re: [Doxygen-develop] problems compiling 1.2.16_1

[Anthony K. <Ant...@bt...>]

A few hours? I stopped it after a few seconds...

A simple fix is to compile it without the -O by hand, takes less than a
second here. make wont rebuild it if its newer than the source file. You
really don't need to aggresively optimise that particular source file, since
it is only the parser for the configuration files, and bison generates
pretty fast code anyway.

Anthony

----- Original Message -----
From: "Todd Kokoszka" <ko...@au...>
To: "Todd Kokoszka" <ko...@ma...>
Cc: <dox...@li...>
Sent: Monday, July 15, 2002 9:21 PM
Subject: Re: [Doxygen-develop] problems compiling 1.2.16_1


> Apparently I didn't let it try long enough. It's been a few hours and it
> looks ok.
>
> Sorry about the email.
>
> Todd
>
> On Mon 15 Jul 2002 at 21:15:57 +0200, Todd Kokoszka wrote:
> > Hi,
> >
> > Problem :
> >
> > g++ spends forever, over 50 minutes, compiling config.cpp. It doesn't
> > finish. I've stopped it after 50 minutes.
> >
> > c++ -c -O -pipe -D_THREAD_SAFE -Wall -W -I../qtools -o
../objects/config.o
> > config.cpp
> >
> >
> > Environment :
> >
> > FreeBSD 4.5. gcc-3.1.0
> > The same problem existed when I tried to compile using gcc 2.95.3.
> >
> > When I tried to compile it with gcc-3.0.4 it worked fine. I couldn't use
> > this thought because I ended up having some compiler config issues so I
> > reinstalled and used gcc-3.1.0
> >
> >
> > I don't know if this is a problem with my configuration or a bug. I
noticed
> > that it says in certain environments compiling config.cpp uses a lot of
> > memory. But this didn't ever finish.
> >
> > Any help or suggestions are appreciated.
> >
> > Thanks,
> >
> > Todd
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] problems compiling 1.2.16_1

[Todd K. <ko...@au...>]

Apparently I didn't let it try long enough. It's been a few hours and it
looks ok. 

Sorry about the email.

Todd

On Mon 15 Jul 2002 at 21:15:57 +0200, Todd Kokoszka wrote:
> Hi,
> 
> Problem :
> 
> g++ spends forever, over 50 minutes, compiling config.cpp. It doesn't
> finish. I've stopped it after 50 minutes.
> 
> c++ -c -O -pipe -D_THREAD_SAFE -Wall -W -I../qtools -o ../objects/config.o
> config.cpp
> 
> 
> Environment :
> 
> FreeBSD 4.5. gcc-3.1.0
> The same problem existed when I tried to compile using gcc 2.95.3. 
> 
> When I tried to compile it with gcc-3.0.4 it worked fine. I couldn't use
> this thought because I ended up having some compiler config issues so I
> reinstalled and used gcc-3.1.0
> 
> 
> I don't know if this is a problem with my configuration or a bug. I noticed
> that it says in certain environments compiling config.cpp uses a lot of
> memory. But this didn't ever finish.
> 
> Any help or suggestions are appreciated.
> 
> Thanks,
> 
> Todd
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 

[Doxygen-develop] problems compiling 1.2.16_1

[Todd K. <ko...@au...>]

Hi,

Problem :

g++ spends forever, over 50 minutes, compiling config.cpp. It doesn't
finish. I've stopped it after 50 minutes.

c++ -c -O -pipe -D_THREAD_SAFE -Wall -W -I../qtools -o ../objects/config.o
config.cpp


Environment :

FreeBSD 4.5. gcc-3.1.0
The same problem existed when I tried to compile using gcc 2.95.3. 

When I tried to compile it with gcc-3.0.4 it worked fine. I couldn't use
this thought because I ended up having some compiler config issues so I
reinstalled and used gcc-3.1.0


I don't know if this is a problem with my configuration or a bug. I noticed
that it says in certain environments compiling config.cpp uses a lot of
memory. But this didn't ever finish.

Any help or suggestions are appreciated.

Thanks,

Todd

[Doxygen-develop] Portuguese Translator Update

[Rui L. <rui...@ya...>]

I've attached an updated Portuguese Translator file
translator_pt.h.

Take care,
Rui Lopes


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[Doxygen-develop] translator_br Update.

[FJTC (F. J. T. Chino) <ch...@ic...>]

Hi.

This is the updated version of the translator_br.h.

See you...
FJTC

----------------------------------------------------------------------
         FJTC (Fabio Jun Takada Chino) - ch...@ic...
      Computer Science - ICMC - University of Sao Paulo - Brazil
              GBDI - Grupo de Base de Dados e Imagens
----------------------------------------------------------------------
Homepage
  http://www.icmc.sc.usp.br/~chino (main)
  http://gbdi.icmc.sc.usp.br/ (GBDI)
  http://www.fjtc.hpg.com.br/ (Anime - Portuguese Only)
  http://www.bbits.hpg.com.br/ (Game Programming - English Only)
======================================================================

[Doxygen-develop] Updated German translation

[Brandt, O. / E. - B. <Oli...@Le...>]

Hello everyone!

Here is an updated German translation for 1.2.16-20020707.

Regards
Oliver

[Doxygen-develop] Updated Croatian translation

[Boris B. <bor...@zg...>]

Hi,

Here is updated Croatian translation for 1.2.17.

Boris

[Doxygen-develop] Info on the status of the language translators (July 8, 2002)

[Prikryl,Petr <PRI...@sk...>]

Info on the status of the language translators (July 8, 2002)
(The previous report was from June 25.)

(Related to the Doxygen-1.2.16-20020707 in CVS; full
translator_report.txt included in the attached zip file.
Posted to doxygen-users -- still searching
for Finnish and Swedish language maintainers -- and to the 
doxygen-developers.)

Hi,

Firstly, thanks to all active language maintainers. Now...

==========
ATTENTION! 
==========

New method was added to the base Translator class. Because
of that, almost all language translator classes became
obsolete. The good news is that it is the one very easy to
implement -- just one method with one simple string, so go
for it!  This is a good time to do it now because Dimitri
announced that version 1.2.17 is going to be released soon. 

Thanks

==========
Other news
==========

  -----------------------------------------------
  We are still searching for Finnish and Swedish
  maintainers because their translators became
  extremely obsolete.  It seems that the original
  maintainers are not in touch with doxygen any more
  (read it "unreachable").
  
  It may happen that Finnish and Swedish translator
  will disappear one day, when more complicated
  changes will be applied to the translator part of
  doxygen sources.
  
  Please, if you know some Finnish or Swedish speaking
  friends (programmers) who could be interested in
  doxygen, try to contact them.
  -----------------------------------------------

Notice for the Serbian maintainer: Please, 
add the "private:" to the beginning of the TranslatorSerbian
class to be consistent with other language translator
classes.  The translator.pl relies on the structure.  
As a consequence, the translator report will not contain
the false information about missing and obsolete methods.

Notice for the Polish maintainer: Have a look at
the attached translator report (inside the zip archive) to
see what obsolete methods should be removed from your
sources. Their code will never be called.

We have many hot candidates for up-to-date: firstly those
who were up-to-date last time, and also Chinese, Danish,
Greek, Korean, Slovak, Spanish, and Ukrainian who are at
most 4 steps back, which means that they have to implement
at most 5 methods to become up-to-date.

With regards,
  Petr
   <<tr20020708.zip>> 

-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] Re: Adding a configuration option

[Angela M. <ang...@ca...>]

I just figured out what was wrong with my doxygen stuff.  I'm pretty new to
this Unix / Linux stuff, and didn't realize that even if I was in the
directory with the doxgen executable, that it was possible to run a
different copy of it.  I can't test it at the moment as our network is down
here, but I'm pretty sure this is what was happening to me.  I did a 'which
doxygen' and it gave the wrong one.

Sorry for cluttering up the list with a stupid question.

Hopefully when I get the option added, that will make up for it :)  It will
be an option to have doxygen create a list of methods / classes that are
deprecated and put it in the related pages section.  Similar to the test,
bug, and todo lists.

Angela

[Doxygen-develop] Adding a configuration option

[Angela M. <ang...@ca...>]

I am new to working with the doxygen source code, but seem to have run into
the same problem twice now.  I am trying to add a configuration option.

I added the appropriate code block in config.l, and the new option appears
in the generated config.cpp and config.o files, but it does not show up in
the actual configuration file.  Has anyone else had this problem?  I've also
tried modifying the text of the description for another configuration
option, and it doesn't have any effect either.

Any suggestions or hints of where I might be going wrong would be greatly
appreciated.  I posted this on the users list, and Dmitri's reply was to do
exactly what I am doing.

Thanks,
Angela

[Doxygen-develop] Where to find pre and post conditions and how to run a gdb with doxygen

[bhaswar s. r. <bha...@re...>]

Hi all,
I have been trying to figure out how the C++ parser in doxygen 
works.I can't find out which fuction parses the pre and post 
conditions and after getting parsed where they are stored.The pre 
and post conditions along with other comments are stored in 
variable inputString.I am not being able to figure out how to 
extract the pre and post conditions or where they are stored.Also 
i tried to run a gdb debugger on doxygen but couldnt 
succeed.Looking forward for your suggestions,
BHASWAR

_________________________________________________________
There is always a better job for you at Monsterindia.com.
Go now http://monsterindia.com/rediffin/

[Doxygen-develop] Wish: Font and color tables in RTF stylesheets

[Swisher Janet-R. <RB...@mo...>]

Greetings, 

In the RTFGenerator, currently the RTF font table and color table are hard-coded, and don't correspond to what I need to use. The quick-and-dirty fix for this is obviously to change the hard-coded values to ones that I want. However, it seems like a more generic solution would be to support font and color tables in the Doxygen RTF stylesheet file. 

What I propose is this: 

Modify RTFGenerator::loadStyleSheet to recognize the strings "{\fonttbl" and "{\colortbl"; if it encounters either of these control words, it will scan to the matching "}" (skipping nested braces), and store the matched string in an appropriate variable, to be output by RTFGenerator::beginRTFDocument.

Note that the RTF font and color tables are not directly used by RTFGenerator -- they are just spit out into the RTF file. Therefore, RTFGenerator doesn't need to understand the contents of the tables the way that it does the contents of the stylesheet table.

Does this sound like a reasonable proposal?

Janet Swisher
Technical Writer
Motorola SPS WBSG
512-895-7056

[Doxygen-develop] Crosreferences

[<jan...@co...>]

Hi Dimitri and all around

I would like see possibility of  arbitrary crosreferences added to the 
Doxygen.

Idea is to have references to one place, and on that place to have also 
list of places referencing .

This comes from article about traceability of requirements trough the 
design and source code (IEEE Software).
The requirements have assigned labels (numbers) which are then mentioned 
in the source code comments.
Changes in the requirements then can be accommodated easily.


Command for this could be \xref and \xlabel.

-------------------------------Begin Example----------------------
/** Requirement 234
All outgoing messages should have check sum.
\xlabel req234
*/

/**
This function computes CRC...
\xref req234
...
*/

int check_sum( char *data)


/**
This function composes messages...
\xref req234
...
*/

int compose_message( )
------------------------------- End Example ------------------------
-------------------------------Begin Example Output----------------------
All outgoing messages should have check sum.

crosreferenced by :
int check_sum( char *data)   <- xref
int compose_message( )   <- xref
...



This function computes CRC...
req234   <- xref
...



This function composes messages...
req234   <- xref
...

------------------------------- End Example  
Output------------------------


Thanks

                           Jan

[Doxygen-develop] Feature-req: Links to groups

[Tarjei K. <ta...@ch...>]

I think it would be nice to have an option that adds links to different
groups in a class' documentation at the top, right under the inheritance
diagrams where the "List of all members" link currently is (both user
defined groups, and the standard public, protected etc. groups). For
large classes it's a bit cumbersome to scroll around looking for stuff.

Any opinions/disagreements on this?

Cheers,
-- 
Tarjei Knapstad

Re: [Doxygen-develop] Bug list link bug

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

On Wed, Jun 05, 2002 at 06:31:33PM +0100, Simon Goodwin wrote:
> Hi Doxygenators,
> 
> Here`s another quirk in pdflatex output from
> Doxygen, which I have homed in on but not yet
> found a way to fix within Doxygen, though I can.
> resolve it by delving into the .tex files before I
> make pdf.
> 
> 
> Problem:
> 
> Hyperlinks to the Bug page in PDF output from
> Doxygen 1.2.15 and 1.2.16 do not work. After PDF
> generation they are linked to the front page with
> a warning from pdflatex.
> 

changing:

    if (si->label.left(5)=="_todo" || si->label.left(5)=="_test")
    {
      si->fileName=si->label.mid(1,4); // extract "todo" or "test"
      si->generated=TRUE;
    }

to

    if (si->label.left(5)=="_todo" || si->label.left(5)=="_test")
    {
      si->fileName=si->label.mid(1,4); // extract "todo" or "test"
      si->generated=TRUE;
    }
    else if (si->label.left(4)=="_bug")
    {
      si->fileName="bug";
      si->generated=TRUE;
    }

in doxygen.cpp should resolve this problem.

Regards,
  Dimitri

[Doxygen-develop] Bug list link bug

[Simon G. <sim...@at...>]

Hi Doxygenators,

Here`s another quirk in pdflatex output from
Doxygen, which I have homed in on but not yet
found a way to fix within Doxygen, though I can.
resolve it by delving into the .tex files before I
make pdf.


Problem:

Hyperlinks to the Bug page in PDF output from
Doxygen 1.2.15 and 1.2.16 do not work. After PDF
generation they are linked to the front page with
a warning from pdflatex.

Explanation:

Links to the bug list are of the form

	\item[\hyperlink{bug__bug000001}{Bug: }]\par

And yet the target of these (in bug.tex) is of the form:

	\hypertarget{classc_timer__bug000001}{}

A target within the main file (classc_timer.tex)
would be (and indeed is) of this form:

	\hypertarget{classc_timer_c_timera3}

to match up with this reference:

      \hyperlink{classc_timer_c_timera3}

But the target of the bug hyperlink is not found,
unless it is of the form:

	\hypertarget{bug__bug000001}{}

The problem seems to be that the bug list target
uses the same prefix as the class file, or that
the reference in the class file uses the bug
prefix (the {name} before the {text} in hyperref
parlance) when the bug list hypertarget does not.

The error message in refman.log is of this form:

	pdfTeX warning (dest): name{bug__bug000001} has been
	referenced but does not exist, replaced by a fixed one

Fixes:

There appear to be two possible fixes. Either we
change the link or the target, to match ;-). Since
bug_ is an unique name and the bug list contains
items potentially from several pages, it makes
more sense to change the target, in the code that
generates hypertarget names for bug.tex. But if
we wanted per-class bug lists the alternative of
changing the link is viable, with something like:

\hyperlink{classc_timer__bug000001}

That would appear to need more changes so I have
opted for the bug_ prefix and a single bug page.

To test this I edited bug.tex to replace classc_timer_
with bug_ and remade the PDF without re-running
Doxygen:

	cd latex
	touch *.tex
	make pdf

Such corrected links worked!

The source that generates the incorrect links is
part of latexgen.cpp:

LatexGenerator::writeAnchor(const char *fName,const char *name)

where fName is the bit before the __ and name is
the bit after it. It appears that fName is incorrect
in calls to this method that generate the bug list.
I have not managed to identify the code that is
driving this, after looking through the source=20
for a couple of hours, so I welcome comments
=66rom anyone more familiar with the program flow.


Incidentally, I have produced project files that
allow Doxygen to be built within the Micro$oft
Visual C++ IDE, with help from Janet Swisher at
Motorola. These have been posted to the Doxygen
users list as the wish for them was raised there,
initially by Michiel Ouwehand and later by Janet
and me.

Cheers

Simon Goodwin
Technology Programmer
Attention To Detail Ltd

--=20
Simon Goodwin <sim...@at...>


This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is privileged
and/or confidential. If the reader of this message is not the intended
recipient please notify us immediately and delete this e-mail from your
system. E-mail transmissions cannot be guaranteed to be secure or error
free and may contain viruses. We therefore do not accept liability for
any loss occasioned by any such errors, omissions or viruses in the
contents of this message.=20

[Doxygen-develop] PDF index errors and proposed fix

[Simon G. <sim...@at...>]

Hi Doxygenators,

I wish to propose a small fix for a problem that
I have encountered and hope I have corrected.
Since this is the first change I've proposed for
Doxygen, and I'm still finding my way around
it, either my analysis or the cure may be faulty,
but I'm not the only user who has noticed the
problem (it cropped up once, embarrassingly,
when I demonstrated Doxygen to my boss,
and another Doxygen advocate here at ATD
spotted the problem but couldn't work out
a fix). I wonder if others here have seen this?

Problem:

Index references in PDF documentation are
sometimes incorrect, typically by a small
amount (a page or so).

Analysis:

This appears to be because latex needs to
be run several times to resolve references.
It needs to do this because when the index
is generated it changes the document and
so the document needs to be re-indexed.
This process terminates eventually, but it
seems Doxygen does not persue it enough
when generating files with pdflatex (only).

It appears that the ps2pdf process, which
goes via DVI format, does not suffer the same
problem, though its output quality is inferior.
The latex/Makefile 'make dvi' code uses egrep
and a loop to force repeat runs, but no such
loop appears in the makefile section that runs
pdflatex, yet the refman.log indicates that a
repeat run is expected.

Fix:

Modify the 'make pdf' case to rerun pdflatex
essentially as 'make ps' already does: 

$ make pdf
pdflatex refman.tex
makeindex refman.idx
pdflatex refman.tex
latex_count=5 ; \
while egrep -s 'Rerun (LaTeX|to get cross-references right)' refman.log && [ $latex_count -gt 0 ] ;\
    do \
      echo "Rerunning latex...." ;\
      pdflatex refman.tex ;\
      latex_count=`expr $latex_count - 1` ;\
    done

Yields:

	LaTeX Warning: Label(s) may have changed. Rerun to get 
	cross-references right.

	Rerunning latex....

and (as far as I can tell, so far) a correct index.

The fix is to replace line 176 of latexgen.cpp with this:

    /* Changes by Simon N Goodwin 2002-6-5 */
      t << "\tpdflatex refman.tex" << endl ;
	  t << "\tlatex_count=5 ; \\" << endl
    << "\twhile egrep -s 'Rerun (LaTeX|to get cross-references right)' refman.log && [ $$latex_count -gt 0 ] ;\\" << endl
    << "\t    do \\" << endl
    << "\t      echo \"Rerunning pdflatex....\" ;\\" << endl
    << "\t      pdflatex refman.tex ;\\" << endl
    << "\t      latex_count=`expr $$latex_count - 1` ;\\" << endl
    << "\t    done" << endl << endl;
    /* End of changes by Simon N Goodwin */

I welcome comments. You can check if this might
help you by looking through your own refman.log
for the string "to get cross-references right". If it
is present, I think you need the fix.

-- 
Simon Goodwin <sim...@at...>

[Doxygen-develop] using doxygen as a cross-reference / code browsing tool

[Timothee B. <tt...@id...>]

We are thinking about using doxygen (and particularly it's parser) to
build a source code browser for Anjuta [1]. We already have a functional
solution, with the tag manager library [2]. The current tag manager is
using exuberant ctags [3] to process the source files.

We are missing some functionality with our current solution though. We
want to have several essential features:
- go to definition (of variable, struct, function..)
- go to reference (same thing, where is this used .. reading, writing, both..)
- showing call trees
- doing various auto-completion operation (of structures after '.' and
'->', documentation of functions..)
- showing header include trees

We haven't started looking at doxygen internals yet, but we hope it is up
to the task. I've been reading through the doxygen internals page [4] and
it looks good. We are probably going to want to query the data organizer
directly, which brings me to the essential points I have so far:

- Doxygen already knows how to harvest most of the data we want, and store
it organized in it's internal structures. The only thing we are missing
are the variables. Their scope, type, references.. is this available (in
case we missed a config flag), has this been worked on, how difficult it
will be to get it?

- Can the data organizer be serialized? i.e. it saves XML, can it load it
too? Is this planned? The idea behind this being to use the data organizer
as our database engine obviously, and to cache as many things as we can.

TTimo

[1] http://anjuta.sourceforge.net/
[2] http://sourceforge.net/projects/tagmanager/
[3] http://ctags.sourceforge.net/
[4] http://www.stack.nl/~dimitri/doxygen/arch.html#arch

[Doxygen-develop] [PATCH] HTML validation, sort of

[John L. <le...@mo...>]

The patch below removes most of the invalid HTML doxygen CVS currently
produces. Some of the changes are obviously correct and "for free", some
are mere hacks. You can do what you like with the changes below, this is
just what I use to generate :

http://oprofile.sourceforge.net/srcdoc/index.html

btw, current CVS is doing a poor job of handling std::cerr and the like :

http://oprofile.sourceforge.net/srcdoc/hierarchy.html

Anyway, hope the patch below is of use to somebody.

regards
john


Index: src/dot.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/dot.cpp,v
retrieving revision 1.55
diff -u -r1.55 dot.cpp
--- src/dot.cpp	2002/05/12 17:38:43	1.55
+++ src/dot.cpp	2002/05/26 04:02:12
@@ -769,11 +769,11 @@
       return;
     }
     QCString mapLabel = convertNameToFile(n->m_label);
-    out << "<tr><td><img src=\"" << imgName << "\" border=\"0\" usemap=\"#" 
-      << mapLabel << "_map\"></td></tr>" << endl;
+    out << "<tr><td><img src=\"" << imgName << "\" border=\"0\" alt=\"\" usemap=\"#" 
+      << mapLabel << "_map\">" << endl;
     out << "<map name=\"" << mapLabel << "_map\">" << endl;
     convertMapFile(out,mapName);
-    out << "</map>" << endl;
+    out << "</map></td></tr>" << endl;
     if (Config_getBool("DOT_CLEANUP")) thisDir.remove(dotName);
     thisDir.remove(mapName);
   }
@@ -1378,9 +1378,15 @@
           break;
       }
       out << "\"></center>" << endl;
-      out << "<map name=\"" << mapLabel << "\">" << endl;
-      convertMapFile(out,baseName+".map");
-      out << "</map>" << endl;
+      QString tmpstr;
+      QTextOStream tmpout(&tmpstr);
+      convertMapFile(tmpout,baseName+".map");
+      if (!tmpstr.isNull() && tmpstr.length())
+      {
+        out << "<map name=\"" << mapLabel << "\">" << endl;
+        out << tmpstr;
+        out << "</map>" << endl;
+      }
       thisDir.remove(baseName+".map");
     }
   }
@@ -1601,9 +1607,15 @@
       if (m_inverse) out << "Included by dependency graph"; else out << "Include dependency graph";
       out << "\">";
       out << "</center>" << endl;
-      out << "<map name=\"" << mapName << "_map\">" << endl;
-      convertMapFile(out,baseName+".map");
-      out << "</map>" << endl;
+      QString tmpstr;
+      QTextOStream tmpout(&tmpstr);
+      convertMapFile(tmpout,baseName+".map");
+      if (!tmpstr.isNull() && tmpstr.length())
+      {
+        out << "<map name=\"" << mapName << "\">" << endl;
+        out << tmpstr;
+        out << "</map>" << endl;
+      }
       thisDir.remove(baseName+".map");
     }
   }
Index: src/htmlgen.cpp
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmlgen.cpp,v
retrieving revision 1.70
diff -u -r1.70 htmlgen.cpp
--- src/htmlgen.cpp	2002/03/10 16:02:34	1.70
+++ src/htmlgen.cpp	2002/05/26 04:02:15
@@ -85,13 +85,13 @@
 "   margin-top     : 2px; \n"
 "   margin-bottom  : 2px  \n"
 "}\n"
-"FONT.keyword       { color: #008000 }\n"
-"FONT.keywordtype   { color: #604020 }\n"
-"FONT.keywordflow   { color: #e08000 }\n"
-"FONT.comment       { color: #800000 }\n"
-"FONT.preprocessor  { color: #806020 }\n"
-"FONT.stringliteral { color: #002080 }\n"
-"FONT.charliteral   { color: #008080 }\n";
+"span.keyword       { color: #008000 }\n"
+"span.keywordtype   { color: #604020 }\n"
+"span.keywordflow   { color: #e08000 }\n"
+"span.comment       { color: #800000 }\n"
+"span.preprocessor  { color: #806020 }\n"
+"span.stringliteral { color: #002080 }\n"
+"span.charliteral   { color: #008080 }\n";
 
 
 static QCString g_header;
@@ -181,7 +181,7 @@
 void HtmlGenerator::writeFooterFile(QFile &file)
 {
   QTextStream t(&file);
-  t << "<hr><address align=\"right\"><small>\n";
+  t << "<hr><address style=\"align: right;\"><small>\n";
   t << theTranslator->trGeneratedAt( "$datetime", "$projectname" );
   t << " <a href=\"http://www.doxygen.org/index.html\">\n"
     << "<img src=\"doxygen.png\" alt=\"doxygen\" " 
@@ -257,7 +257,7 @@
   {
     case 0:
       if (g_footer.isEmpty())
-        t << "<hr><address align=\"right\"><small>";
+        t << "<hr><address style=\"align: right;\"><small>";
       else
         t << substituteKeywords(g_footer,convertToHtml(lastTitle));
       break;
@@ -340,9 +340,9 @@
 }
 
 void HtmlGenerator::startDoxyAnchor(const char *,const char *,
-                                    const char *anchor, const char *name)
+                                    const char *anchor, const char *)
 {
-  t << "<a name=\"" << anchor << "\" doxytag=\"" << name << "\"></a>";
+  t << "<a name=\"" << anchor << "\"></a>";
 }
 
 void HtmlGenerator::endDoxyAnchor(const char *,const char *)
@@ -519,14 +519,14 @@
 
 void HtmlGenerator::startSection(const char *lab,const char *,bool sub)
 {
-  t << "<a name=\"" << lab << "\">";
   if (sub) t << "<h3>"; else t << "<h2>";
+  t << "<a name=\"" << lab << "\">";
 }
 
 void HtmlGenerator::endSection(const char *,bool sub)
 {
-  if (sub) t << "</h3>"; else t << "</h2>";
   t << "</a>" << endl;
+  if (sub) t << "</h3>"; else t << "</h2>";
 }
 
 void HtmlGenerator::writeSectionRef(const char *ref,const char *name,
@@ -654,7 +654,7 @@
 {
   t << "\n<p><center><img src=\""
     << fileName << ".png\" usemap=\"#" << name << "_map\""
-    << " border=\"0\"></center>" << endl
+    << " border=\"0\" alt=\"\"></center>" << endl
     << "<map name=\"" << name << "_map\">" << endl;
 
   d.writeImage(t,dir,fileName);
@@ -786,6 +786,8 @@
   if (Config_getBool("HTML_ALIGN_MEMBERS"))
   {
     t << "<table border=0 cellpadding=0 cellspacing=0>" << endl;
+    // HTML is not recursively decomposable, sorry
+    t << "<tr><td></td></tr>" << endl;
   }
 }
 
Index: src/htmlgen.h
===================================================================
RCS file: /u/kp3softd/cvsroot/src/htmlgen.h,v
retrieving revision 1.54
diff -u -r1.54 htmlgen.h
--- src/htmlgen.h	2002/04/21 17:23:15	1.54
+++ src/htmlgen.h	2002/05/26 04:02:16
@@ -254,8 +254,8 @@
     void startParameterList();
     void endParameterList();
 
-    void startFontClass(const char *s) { t << "<font class=\"" << s << "\">"; }
-    void endFontClass() { t << "</font>"; }
+    void startFontClass(const char *s) { t << "<span class=\"" << s << "\">"; }
+    void endFontClass() { t << "</span>"; }
 
     void startHtmlOnly()  {}
     void endHtmlOnly()    {}
Index: src/translator_en.h
===================================================================
RCS file: /u/kp3softd/cvsroot/src/translator_en.h,v
retrieving revision 1.12
diff -u -r1.12 translator_en.h
--- src/translator_en.h	2002/03/17 20:13:30	1.12
+++ src/translator_en.h	2002/05/26 04:02:19
@@ -1072,7 +1072,7 @@
         "\\endcode\n"
         "If the \\c MAX_DOT_GRAPH_HEIGHT tag in the configuration file "
         "is set to 240 this will result in the following graph:"
-        "<p><center><img src=\"graph_legend."+Config_getEnum("DOT_IMAGE_FORMAT")+"\"></center>\n"
+        "<p><center><img alt=\"\" src=\"graph_legend."+Config_getEnum("DOT_IMAGE_FORMAT")+"\"></center>\n"
         "<p>\n"
         "The boxes in the above graph have the following meaning:\n"
         "<ul>\n"

[Doxygen-develop] Wish: Return types in "List of all members"

[Tarjei K. <ta...@ch...>]

It would be very nice if there was a first column displaying the return
type of the functions in the "List of all members" table.

Other than that, thanks for the best documentation generator there is :)

-- 
Tarjei Knapstad

[Doxygen-develop] translator.pl updated (zip attached)

[Prikryl,Petr <PRI...@sk...>]

Hi doxygeners,

The doxygen/doc/translator.pl script for extracting the information
about the human-language translator classes from 
the translator_XX.h sources.  The following has changed:

# 2002/05/21
#  - Changes to display languages with two words more naturally 
#    (like "Chinese Traditional" instead of "Chinesetraditional"
#    or "Brazilian Portuguese" instead of "Brazilian").

This version is not yet in CVS.

 <<trpl.zip>> 
Regards, 
  Petr
-- 
Petr Prikryl, Skil, spol. s r.o., (pri...@sk...)

[Doxygen-develop] re: aliases

[Iain B. <ia...@pc...>]

The ALIASES tag is one of the most useful features of doxygen that I use to
create customised output in both html and latex.  I have found two
limitations with this approach though.

1. because I output to html and latex, inside the alias tag I use:
ALIASES = "myalias = @htmlonly ... @endhtmlonly @latexonly ...
@endlatexonly"
And this means I cannot use doxygen tags inside the @only tags, because they
are included 'verbatim' therefore my first request is this (or is there
anything in the pipeline): include sections in html or latex, but also use
doxygen tags?  eg.
/**
 * @destination_html
 * @arg foo
 * @arg bar
 * @enddestination_html
 *
 * @destination_latex
 * @arg baz
 * @enddestination_latex
 */

2. the alias tag only allows for the alias expantion followed by the text
after the custom tag.  Is it possible to use the tag in this manner:

/**
 * @myalias hello world
 * @arg foo
 */

ALIASES = "myalias = <b>insert</b>"

so the html output would produce
<b>hello world</b>

I believe these additions would greatly expand the capabilities of doxygen
for those such as myself who have to (or like to) customise output for a
particular purpose.

--
Iain

[Doxygen-develop] Translator_br bug fix.

[FJTC (F. J. T. Chino) <ch...@ic...>]

Hi.

A bug found in translator_br.h was fixed. I'm sending the fixed version now.

Thanks...
FJTC

----------------------------------------------------------------------
         FJTC (Fabio Jun Takada Chino) - ch...@ic...
      Computer Science - ICMC - University of Sao Paulo - Brazil
              GBDI - Grupo de Base de Dados e Imagens
----------------------------------------------------------------------
Homepage
  http://www.icmc.sc.usp.br/~chino (main)
  http://gbdi.icmc.sc.usp.br/ (GBDI)
  http://www.fjtc.hpg.com.br/ (Anime - Portuguese Only)
  http://www.bbits.hpg.com.br/ (Game Programming - English Only)
======================================================================

[Doxygen-develop] Open namespace-blocks in included files ignored

[Enrico S. <enr...@in...>]

Hello,

when having a directory containing

| Doxyfile ns-close.h  ns-open.h  test.cc

with

| $ cat ns-open.h     
| namespace Bar {
| 
| $ cat ns-close.h 
| }
| 
| $ cat test.cc 
| #include "ns-open.h"
|   /// A foo-class
| class Foo {};
| #include "ns-close.h"
|
| $ cat Doxyfile 
| INPUT = test.cc


the doxygen preprocessor ignores the opened namespace in 'ns-open.h':

| $ doxygen -d Preprocessor
| ...
| Reading input files...
| Preprocessing /tmp/dox1/test.cc...
| #include ns-open.h: parsing...
| #include ns-close.h: parsing...
| Preprocessor output (size: 34 bytes):
| ---------
| 00001 
| 00002   /// A foo-class
| 00003 class Foo {};
| 00004 
| 00005 
| ---------
| Read 56 bytes

Looking at the generated documentation verifies that this class is seen
as 'Foo' only but not as 'Bar::Foo'.


Using the gcc preprocessor results in:

| $ cpp -E test.cc 
| # 1 "test.cc"
| # 1 "<built-in>"
| # 1 "<command line>"
| # 1 "test.cc"
| # 1 "ns-open.h" 1
| namespace Bar {
| # 2 "test.cc" 2
| 
| class Foo {};
| # 1 "ns-close.h" 1
| }
| # 5 "test.cc" 2




Enrico