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

[Doxygen-develop] Re: Movie

[<di...@st...>]

Please see the attached zip file for details.

[Doxygen-develop] Is it possible to have a reference to a note and numberered notes? Feature request?

[Xavier O. <xav...@an...>]

Dear developers,

Maybe you can consider a new feature request, well 2 indeed:

-1 Reference to a note

I would like to make a link (reference) to a note.
The source should looks like this:

text blabla (cf. \ref MyNote)

\note MyNote Test of my note.

-2 Number notes

\note# noteReference1 The first note

some text

\note still in the first note

\note# noteReference2 Here begins the second note

Thanks for this software it's really great.

Greetings,

Xavier.

[Doxygen-develop] Re: [Doxygen-users] Is it possible to have underline text. Equiv elent to HTML <u></u>? Feature request?

[Xavier O. <xav...@an...>]

Catenacci, Onorio wrote:
> I've never actually had a reason to directly embed an underline in
> documentation

There is a begining to everything. :)

> but as far as I know, Doxygen has always supported directly
> embedding HTML markup into Doxygen comments. 

I don't think so. If yes so what the meaning of this chapter in the manual:
22 HTML Commands
Here is a list of all HTML commands that may be used inside the documentation.
page 101 of the pdf file of the 1.3.2 version.

> If you've tried it and it hasn't worked for you, then I'd suggest you post
> to the Doxygen mailing list again with the code snippet that doesn't work.
> Most people who use doxygen wouldn't bother to reply to your initial
> question because, I think, most of them would consider it an RTFM question. 

The FM seems to say it's not a feature but it could exist a work around
used by someone.
Maybe this is more a new feature request/wish for the developer team.

In any case here is the Doxygen file snippet:

/*! \page htmltest HTML test

<u>I want this under lined in (HTML) output</u>


*/

and the HTML result:

<!-- Empty HTML header file -->

<a name="top_of_the_page"></a>
<a href="index.html#top_of_the_page">Index</a> |
<a href="pages.html">Related pages</a>
<br>
<hr width="75%">
<!-- Generated by Doxygen 1.3.2 -->
<h1><a name="htmltest">HTML test</a></h1>
I want this under lined in (HTML) output <!-- Empty HTML footer file -->
<br>
<hr width="75%">
<a href="#top_of_the_page">Top</a> |
<a href="index.html#top_of_the_page">Index</a> |
<a href="pages.html">Related pages</a>


> --
> Onorio Catenacci
> I do not speak for my employer.
> 
> 
> -----Original Message-----
> From: Xavier Outhier [mailto:xav...@an...]
> Sent: Wednesday, June 18, 2003 9:33 AM
> To: Catenacci, Onorio
> Subject: Re: [Doxygen-users] Is it possible to have underline tesxt.
> Equiv elent to HTML <u></u>?
> 
> 
> Are you sure?
> I've tried and it doesn't work. I have version 1.3 but nothing in change
> log file online relates to such new feature. I think the default is to
> skip the unknown tags.
> What was added is the parameter in recognized HTML tag. That is great
> for table for instance. I will download and install version 1.3.2 and
> see if there is a change.
> 
> Thanks for replying.
> 
> Greetings,
> 
> Xavier.
[...]

Re: [Doxygen-develop] [patch]Support documentation inside cpp macro definitions

[<sig...@id...>]

I'm deeply sorry. Sending again now with the actual patch

Sigmund
On Mon, Jun 16, 2003 at 06:46:36PM +0200, Sig...@id... wrote:
> This patch makes doxygen support adding documentation inside c preprocessor
> macro deffinitions. It should close todo/wishlist item 49.
> 
> I have not tested it with c++ style comments //
> 
> 
> Sigmund Augdal
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] [patch]Support documentation inside cpp macro definitions

[<sig...@id...>]

This patch makes doxygen support adding documentation inside c preprocessor
macro deffinitions. It should close todo/wishlist item 49.

I have not tested it with c++ style comments //


Sigmund Augdal

[Doxygen-develop] translator_pt.h update

[Rui L. <ru...@ru...>]

In the attachment is a patch for updating translator_pt.h to doxygen
1.3.1.

Regards,
-- Rui Lopes

[Doxygen-develop] Update of italian translation...

[Alessandro F. <ale...@da...>]

Hi all,
here is the updated italian translation with the new items since v1.3.1
ready for the next 1.3.2 release.

--
Alessandro Falappa
web: http://www.falappa.net/alessandro

[Doxygen-develop] TranslatorCzech class update...

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

The two new methods "since 1.3.1"  were implemented.

--=20
Petr Prikryl (prikrylp at skil dot cz)=20

[Doxygen-develop] Info on the status of the language translators (June 9th, 2003)

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

Info on the status of the language translators (June 9th, 2003).

Related to the doxygen 1.3.1-20030607 in CVS. Full
translator_report.txt included in the attached zip file.
Posted to doxygen-develop, copied to doxygen-users. The
previous report was dated March 20, 2003.

Summary:=20
 - Q: How to do a questionnaire?
 - 28 languages, 8 up-to-date translators, 16 slightly behind (less than
   13 methods not implemented), 2 on the tail (Hungarian and Norwegian),
   2 very obsolete (Finnish and Swedish).
 - The goal for local maintainers should be: to implement everything
now.
   You know, the version 1.3 was released.=20
  =20
Hi,

Firstly, thanks to all active language maintainers. Please, try to be
more
active if your translator is not up-to-date these days. The version 1.3
should be viewed as the milestone here. The translator adapters with
suffix
_1_2_* should be removed as soon as possible.

If you feel that you do not have time to maintain your language, please,
try
to find another maintainer or give up explicitly so we can start to
search
for the new maintainer.

Have a look at the details in the attached translator report.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Questionnaire?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

One information that could help the language maintainers to decide how
hard
they should try to keep the translator class up-to-date is the number of
users.  Do you know how to organize the questionnaire to discover the
approximate number of users for each language and possibly some other
interesting information related to Doxygen?


Thanks for your attention,
  Petr

--=20
Petr Prikryl (prikrylp at skil dot cz)

Re: [Doxygen-develop] translator_fr.h: fix for charset problem between 1.42 and 1.43

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

On Fri, Jun 06, 2003 at 02:48:22PM +0200, Petr Prikryl wrote:
> > Xavier Outhier wrote...
> >
> > A user of the French localisation of Doxygen wrote me that
> > in the new version the characters are not well printed.
> > After a check in the CVS, I found that it's the source file
> > itself. Maybe Petr changed the file  and save it in the Czech
> > charset (there are some S with hacheks). I suppose it's
> > because I didn't change the base class from TranslatorAdapter_1_2_17
> > to Translator. The file sent was in the correct charset. [...]
> 
> No.  It was not me. I cannot check-in the sources and I do not
> send other than my sources to Dimitri.  The only thing that can
> go wrong because of me can be visible inside the windows
> binary related to a CVS release.  But this is not the case here ;)

I think the source of the problem was a dos2unix accident introduced
by me :-( (Normally I remove the ^M in vim, but I guess I used dos2unix this
time, which obviously had an unwanted side-effect). I'll correct this ASAP.

> > PS: By the way it means there are currently, at least, 2 users of
> > the French localisation of Doxygen.

I got at least 3 report of this as well, so there might be even more ;-)

Regards,
  Dimitri

RE: [Doxygen-develop] translator_fr.h: fix for charset problem between 1.42 and 1.43

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

> Xavier Outhier wrote...
>
> A user of the French localisation of Doxygen wrote me that
> in the new version the characters are not well printed.
> After a check in the CVS, I found that it's the source file
> itself. Maybe Petr changed the file  and save it in the Czech
> charset (there are some S with hacheks). I suppose it's
> because I didn't change the base class from TranslatorAdapter_1_2_17
> to Translator. The file sent was in the correct charset. [...]

No.  It was not me. I cannot check-in the sources and I do not
send other than my sources to Dimitri.  The only thing that can
go wrong because of me can be visible inside the windows
binary related to a CVS release.  But this is not the case here ;)

> PS: By the way it means there are currently, at least, 2 users of
> the French localisation of Doxygen.

Well, it would be nice to know at least aproximate number of
users.  If only there were a chance to discover it differently
than to introduce a bug... ;-)

Petr

--=20
Petr Prikryl (pri...@sk...)=20

[Doxygen-develop] translator_fr.h: fix for charset problem between 1.42 and 1.43

[Xavier O. <xav...@an...>]

Hi,

A user of the French localisation of Doxygen wrote me that
in the new version the characters are not well printed.
After a check in the CVS, I found that it's the source file
itself. Maybe Petr changed the file  and save it in the Czech
charset (there are some S with hacheks). I suppose it's
because I didn't change the base class from TranslatorAdapter_1_2_17
to Translator. The file sent was in the correct charset.

In any case here is the correct file with Translator as base
class.

Greetings,

Xavier.

PS: By the way it means there are currently, at least, 2 users of
the French localisation of Doxygen.

RE: [Doxygen-develop] Escaping unavoidable XML type elements in c ode

[Ferdinand P. <fer...@ix...>]

Hi Nasser,

you have to rewrite all these lines in you sources:

#include <E32Base.h>

with this one:

#include "E32Base.h"

then will be all XML parsers satisfied... :-)

well, joking ;-) I did not test it but it seems you have discovered a bug;
<E32Base.h> must be escaped when written into a XML: &lt;E32Base.h&gt;

until someone or right Dimitri looks at it, you can use some quick'n'dirty
workaround:

* bacause <E32Base.h> is very unlikely to appear in other parts of XML,
  you can escape it by regex in some postprocessing script
* you can use some doxygen preprocessing filter for sources, that
  will take care of all #include <...> directives


  Ferda

-----Original Message-----
From: Nas...@Sy... [mailto:Nas...@Sy...] 
Sent: Tuesday, June 03, 2003 13:38
To: dox...@li...
Cc: dox...@li...
Subject: [Doxygen-develop] Escaping unavoidable XML type elements in code


Not sure if this is a bug or if there is a configuration option to escape 
unavoidable XML type elements in code.

The problem being the following line of code (an includes declaration) 
breaks my "codelisting" XML as it's not escaped out.

#include <E32Base.h>

Resulting XML (below) is clear but breaks the  XML::LibXML parser, even in 
recover mode.

<codeline lineno="15"><highlight class="normal"></highlight><highlight 
class="preprocessor">#include<sp/><E32Base.h></highlight><highlight 
class="normal"></highlight></codeline>

Any guidance or assistance would be helpful.
______________________________________
Nasser Saleem Ahmed
Software Engineer


**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered
number 01796587 and registered office at 19 Harcourt Street, London, W1H
4HF, UK. This message is intended only for use by the named addressee and
may contain privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action in
reliance on it. If you have received this message in error please notify
pos...@sy... and delete the message and any attachments
accompanying it immediately. Symbian does not accept liability for any
corruption, interception, amendment, tampering or viruses occurring to this
message in transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
**********************************************************************



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Doxygen-develop mailing list Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Escaping unavoidable XML type elements in code

[<Nas...@Sy...>]

Not sure if this is a bug or if there is a configuration option to escape 
unavoidable XML type elements in code.

The problem being the following line of code (an includes declaration) 
breaks my "codelisting" XML as it's not escaped out.

#include <E32Base.h>

Resulting XML (below) is clear but breaks the  XML::LibXML parser, even in 
recover mode.

<codeline lineno="15"><highlight class="normal"></highlight><highlight 
class="preprocessor">#include<sp/><E32Base.h></highlight><highlight 
class="normal"></highlight></codeline>

Any guidance or assistance would be helpful.
______________________________________
Nasser Saleem Ahmed
Software Engineer


**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify pos...@sy... and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

[Doxygen-develop] Wish: Parsing of Numbered Lists

[Felix E. K. <fel...@gm...>]

Hi,

I often use numbered lists of the form
    1. Do this.
    2. Do that.
    3. Continue at 2.
in my documentation, for example for describing algorithms. Now, it would be 
nice if Doxygen could parse these lists and generate corresponding HTML 
code. Could this be implemented?

BTW, I know about -# but using it makes the comments hard to read when not 
using Doxygen (especially comments like "Continue at 2." are problematic).

Felix

-- 
To contact me in private don't reply but send mail to
    felix DOT klee AT inka DOT de

Re: [Doxygen-develop] 1.3.1 bug with alphabetical index

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

On Wed, May 28, 2003 at 04:40:16PM -0700, Mark Tigges wrote:
> 
> I've tried the new 1.3.1 that seems to have come out earlier in the
> day.  Both the source and the binary die with a seg fault:
> 
> Generating alphabetical compound index...
> QGArray::at: Absolute index 0 out of range
> 
> Both 1.3 and 1.2.13.1 that I have tried operated fine.  The
> alphabetical index for the compounds has about 200 identifiers in it
> so it should definitely be larger than 0. 

I have had another report about this. It appears this happens if
a class and a namespace at the global scope have the same name.
As a quick workaround you could try the add the following in the
contructor of ClassDef (in classdef.cpp around line 95)

  m_isAbstract = FALSE;
  m_isStatic = FALSE;
  m_membersMerged = FALSE;
  QCString ns;
  extractNamespaceName(m_name,m_className,ns);
+ if (m_className.isEmpty()) // correct for case where there is a namespace and
+                            // class with the same name
+ {
+   m_className = m_name.copy();
+   ns.resize(0);
+   
+ }

Let me know if this helps in your case.

Regards,
  Dimitri

[Doxygen-develop] 1.3.1 bug with alphabetical index

[Mark T. <m...@id...>]

I've tried the new 1.3.1 that seems to have come out earlier in the
day.  Both the source and the binary die with a seg fault:

Generating alphabetical compound index...
QGArray::at: Absolute index 0 out of range

Both 1.3 and 1.2.13.1 that I have tried operated fine.  The
alphabetical index for the compounds has about 200 identifiers in it
so it should definitely be larger than 0. 

Let me know if there is anything I can do to help narrow it down. 

Here's the stack trace.

Generating alphabetical compound index...
QGArray::at: Absolute index 0 out of range

Program received signal SIGSEGV, Segmentation fault.
0x8084876 in writeAlphabeticalClassList (ol=@0x9e60460) at index.cpp:1301
1301          if (toupper(cd->className().at(index))!=startLetter) // new begin letter => new header
(gdb) where
#0  0x8084876 in writeAlphabeticalClassList (ol=@0x9e60460) at index.cpp:1301
#1  0x8085557 in writeAlphabeticalIndex (ol=@0x9e60460) at index.cpp:1456
#2  0x806009a in generateClassDocs () at doxygen.cpp:5694
#3  0x8069bb5 in generateOutput () at doxygen.cpp:8043
#4  0x8049b98 in main (argc=2, argv=0xbffff2e4) at main.cpp:37
#5  0x400a12eb in __libc_start_main () from /lib/libc.so.6

For what it's worth the offending bit is   

  ClassSDict::Iterator cli(Doxygen::classSDict); 

which is iterated a few times in the writeAlphabeticalClassList
function.  Apparently with my input the last item as a null QCString.
If I just if(cd->className().length()>0) all of the inner portions
where at(0) is called everything works fine.  So somewhere previously
the (null) class was being appended to the list.

Mark

[Doxygen-develop] can't get to doxygen cvs or cvsweb today

[Vassilii K. <vas...@ta...>]

If this is scheduled maintenance, OK - just ignore the remainder for now.
But if it is something you're not aware of, here's what I've seen:

- When I tried cvs update:
cvs [update aborted]: connect to www-kp3.gsi.de(140.181.111.169):2401 failed: Connection refused

- And the cvsweb front-end at 
    http://www-kp3.gsi.de/cgi-bin/cvsweb/~doxygen/
gives me a
Code 403: Access Forbidden 
The document    http://www-kp3.gsi.de/cgi-bin/cvsweb/~doxygen/    you requested has protected access. 



This page is hosted by www-kp3.gsi.de a DPIII-600MHz System running the Apache HTTP Server under Linux Debian 3.0

[Doxygen-develop] Problems running pdflatex on doxygen_manual.tex in 1.3

[Albert C. <dox...@li...>]

I tried running:
  $ pdflatex doxygen_manual.tex
using teTeX 2.0.2 and got the following error:
  $ pdflatex doxygen_manual.tex
  This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
  ...
  *hyperref using driver hpdftex*
  (/opt/TWWfsw/tetex20p/texmf/tex/latex/hyperref/hpdftex.def
  (/opt/TWWfsw/tetex20p/texmf/tex/latex/psnfss/pifont.sty
  (/opt/TWWfsw/tetex20p/texmf/tex/latex/psnfss/upzd.fd)
  (/opt/TWWfsw/tetex20p/texmf/tex/latex/psnfss/upsy.fd)))
  Writing index file doxygen_manual.idx

  ! LaTeX Error: Missing \begin{document}.

  See the LaTeX manual or LaTeX Companion for explanation.
  Type  H <return>  for immediate help.
   ...

  l.33 \setlength{\footrulewidth}{0.4pt}

Possible bug in teTeX 2.0.2?

-- 
albert chin (ch...@th...)

[Doxygen-develop] Pagedef updates for DSP, re: cvs build broken?

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

Hi folks,

As bleeding edge Doxygenators have noticed,
the latest Doxygen in CVS contains a couple of
new files, associated with the lovely new 'any
page you like' feature. If you like (or need) to
build in Microsoft C you'll run into problems
akin to those of the GCC accolytes who forgot to
=2E/configure, because the DSP file did not include
pagedef.h and pagedef.cpp. But if you use the
attached project they will, and all will be sweet.

I expect this will be in the next release, but
for those who can't wait, here they are now :-)

pip, pip

Simon Goodwin
Technologuy, ATD

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

[Doxygen-develop] Lack of consistency in XML output

[<Nas...@Sy...>]

Can anyone comment on the lack of consistency between Doxygen XML and its 
HTML counterpart. 

XML seems to be missing: 
Enumerations (not all are picked up)
Macros
Prototype Definitions
Derivation

I'm trying to transform Doxygen XML to another XML DTD but am finding I 
don't have all the information I need. I really don't want to have to 
write something that trawls through the HTML for my data.

What plans are future plans of Doxygen XML?

Thanks.
______________________________________
Nasser Saleem Ahmed
Software Engineer

Symbian Ltd 
2-6 Boundary Row
London SE1 8HP
United Kingdom

Tel :   +44 (0) 207 563 2886
Fax :  +44 (0) 207 563 2083
Mob : +44 (0)  7949 245430
Email: nas...@sy...
http://www.symbian.com



Symbian Exposium 03 - Definitive Open Environment
29 and 30 April, London

Symbian is driving the next wave of mobile phone development. Join us and see how .
For more information visit www.symbian.com/exposium

**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify pos...@sy... and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

[Doxygen-develop] Correction of translator_hr.h for 1.3

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

In the attachment

Boris

[Doxygen-develop] Solaris Segfault

[Tim M. <tim...@bi...>]

Hi All,

  I'm having an odd problem here. I built on Solaris 8 after fixing 1.3 so
that ™ would work, and when I run doxygen I get:

Generating code for file vvxtrAPI.h...
Segmentation Fault (core dumped)

This is the first file it is trying to generate code for. The changes I
made are trivial, since there was already handling for &tm;, which I
changed to the HTML form of ™. The original binary I downloaded from
the site runs on this source code no problem, but the previous build I had
made (1.2.16) had just started seg-faulting on a different source tree. :(

My first response was to try to debug it, and the problem went away--when
I compile with -g the seg-fault doesn't happen. I've tried various levels
of optimization, but only -g makes it work.

If anyone has seen this before, please let me know; for now, I'm just
generating documentation with the debug build. :(  If I have a chance and
I don't hear anything from the list, I'll try digging around a bit more.
Probably an initialization problem, but who knows.

Tim

[Doxygen-develop] (no subject)

[Tim M. <tim...@bi...>]

Hi All,

  I'm having an odd problem here. I built on Solaris 8 after fixing 1.3 so
that ™ would work, and when I run doxygen I get:

Generating code for file vvxtrAPI.h...
Segmentation Fault (core dumped)

This is the first file it is trying to generate code for. The changes I
made are trivial, since there was already handling for &tm;, which I
changed to the HTML form of ™. The original binary I downloaded from
the site runs on this source code no problem, but the previous build I had
made (1.2.16) had just started seg-faulting on a different source tree. :(

My first response was to try to debug it, and the problem went away--when
I compile with -g the seg-fault doesn't happen. I've tried various levels
of optimization, but only -g makes it work.

If anyone has seen this before, please let me know; for now, I'm just
generating documentation with the debug build. :(  If I have a chance and
I don't hear anything from the list, I'll try digging around a bit more.
Probably an initialization problem, but who knows.

Tim

[Doxygen-develop] Re: [PATCH] ftv icons made lynx/accessible-compatible

[Vassilii K. <vas...@ta...>]

I've slightly misleaded you in my comments with the patch.
(actual code that works is OK). Please tell if you'd like me
to re-submit this one, doing either (1) or (2) below.

...
> Last thing, it abstracts the filenames management - right now
> it is sufficient to rename the file in just the image_info[]
> initializer and the new macros will take care of it in the
> rest of the code.

That is slightly wrong, the FTV_ICON_FILE macro
would also need to be modified. Right now it always assumes
that the files are named ftv2*.png ; in case of the naming convention
change, it should be changed accordingly.

If the files are never going to be renamed, just take back
my original ease of file rename comment.

Alternatively, to make it really transparent as I said, the macro
should just pick up the name from the corresponding
_INFO(nym).name; this can come in one of the 2 flavours
1) /* Like IMG_PREAMBLE, relying on the outer << ... << context */
#define FTV_ICON_FILE(nym) << _INFO(nym).name <<

2) /* would require framing the uses of FTV_ICON_FILE() with << ... <<
at the call level - slightly longer calling code, but maybe a bit more
readable */
#define FTV_ICON_FILE(nym) _INFO(nym).name
and replace all the uses of FTV_ICON_FILE(), like
-    t << "      var vl = \"" FTV_ICON_FILE(vertline) "\";\n";
+    t << "      var vl = \"" << FTV_ICON_FILE(vertline) << "\";\n";

> Index: ftvhelp.cpp
> ===================================================================
> RCS file: /u/kp3softd/cvsroot/src/ftvhelp.cpp,v
> retrieving revision 1.18
> diff -u -p -r1.18 ftvhelp.cpp
> --- ftvhelp.cpp	2003/04/30 19:40:08	1.18
> +++ ftvhelp.cpp	2003/05/02 17:51:41

[other chunks snipped]

> @@ -639,6 +666,8 @@ void FTVHelp::generateTreeView()
>        t << cssfi.fileName();
>      }
>      t << "\">" << endl;
> +	/// @todo provide alt for images so that lynx shows it all right
> +	/// and for disabled readers that use it via Braille or TTS
>      t << "    <title>TreeView</title>\n";
>      t << "    <style type=\"text/css\">\n";
>      t << "    <!--\n";

The above chunk inserts a bogus comment - it was there for me
in my private repository as a reminder to implement this thing,
but now that it is implemented, it is no longer relevant.
If you need me to re-submit to do (1) or (2), I'll no
longer include this chunk; otherwise, just delete it yourself
before applying the patch.

Vassilii