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

[Doxygen-develop] Re: Wikipedia entry problems

[Martin F. <mar...@gm...>]

Hello,

> Also for the doxygen page itself in the german wikipedia
> the article is proposed to be deleted.
>  http://de.wikipedia.org/wiki/Doxygen

I added a comment on the Wiki discussion page with my veto
against the deletion:

http://de.wikipedia.org/wiki/Diskussion:Doxygen

I think if you (or some one else) extends the article, it won't be
deleted. Currently it's a bit short.
However the complete version story is a thing, which IMHO should not
necessary be kept in the Wikipdedia article. The Doxygen web site
is a better place for this list.

Regards,

    Martin

[Doxygen-develop] Wikipedia entry problems

[Enno B. <enn...@t-...>]

Hi

I just discovered that the German doxygen article about the
version of Doxygen has been deleted without any comment
and it was deleted without the process of "proposing to be deleted"
  http://de.wikipedia.org/wiki/Spezial:Undelete/Doxygen_--_Versionsliste

Also for the doxygen page itself in the german wikipedia
the article is proposed to be deleted.
  http://de.wikipedia.org/wiki/Doxygen

To not lose the version informations that were discribed in that 
article I did write them down in a text file
"version_history.txt" that is attachted to this email.

So it would be nice if this file could be added to the next 
version of doxygen in the sources. 

Thanks for listening

Enno

Re: [Doxygen-develop] Re: Macroized Functions

[Duane E. <dua...@fr...>]

> Did you check the PREDEFINED and EXPAND_AS_DEFINED config options?
> I think something like 'PREDEFINED = "TRAPFUNC(a,b,c)=a b c"' would do
> the trick.

There are so many options --- I did not see this. I just tried it... Sadly 
- it does not do the trick.

Such is life.... we plod on.

-Duane.

[Doxygen-develop] Re: Macroized Functions

[Frank R. <fra...@gm...>]

On 13.10.2005 18:49, Duane Ellis wrote:
> I've tried:
> 
> #ifdef DOXYGEN
> #define TRAPCALL( X, Y, Z )      X Y Z
> #endif
> 
> but that does not help, doxygen does not expand #defines.
> 
> Doing #ifdef DOXYGEN blocks around hundreds of API function is *NOT* a 
> good idea.

Did you check the PREDEFINED and EXPAND_AS_DEFINED config options?
I think something like 'PREDEFINED = "TRAPFUNC(a,b,c)=a b c"' would do
the trick.

-f.r.

RE: [Doxygen-develop] Macroized Functions

[Michael M. <Mic...@tt...>]

Hi Duane,

I made a patch to allow \def to be used to force documentation of a define,
even if the #define is not found in the source code.  It was for a similar
problem that I made this mod.

I reported it as a bug in Bugzilla, and the patch for 1.4.3 is attached to
that.  See "Bug 310895: Cannot document non-existant defines with \def".
Maybe this could be a help to you?

Regards,

Mike

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-develop-
> ad...@li...] On Behalf Of Duane Ellis
> Sent: 13 October 2005 17:50
> To: dox...@li...
> Subject: [Doxygen-develop] Macroized Functions
> 
> We are using doxygen to document some C code for a bios.
> 
> Hundreds of functions are defined via macros. For example:
> 
> /** Set the platform RTC Clock to specified time (TZ=GMT)
> * \param p_date - Pointer to the date
> * \return  TRUE success, FALSE error (platform lacks RTC)
> */
> TRAPFUNC(   BOOL,  biosRtcSetGMT,   ( RTC_DATE *p_data ) );
> 
> The problem is the "TRAPFUNC" macro. The "trapfunc" macro creates multiple
> 
> instances of the function name - addorned with attributes and does ohter
> things.
> (the same header file is compiled in multiple ways) {It simplifies many
> many things
> We really don't want to change that.}
> 
> I've tried:
> 
> #ifdef DOXYGEN
> #define TRAPCALL( X, Y, Z )      X Y Z
> #endif
> 
> but that does not help, doxygen does not expand #defines.
> 
> Doing #ifdef DOXYGEN blocks around hundreds of API function is *NOT* a
> good idea.
> 
> Any suggestions?
> 
> -Duane.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Macroized Functions

[Duane E. <dua...@fr...>]

We are using doxygen to document some C code for a bios.

Hundreds of functions are defined via macros. For example:

/** Set the platform RTC Clock to specified time (TZ=GMT)
* \param p_date - Pointer to the date
* \return  TRUE success, FALSE error (platform lacks RTC)
*/
TRAPFUNC(   BOOL,  biosRtcSetGMT,   ( RTC_DATE *p_data ) );

The problem is the "TRAPFUNC" macro. The "trapfunc" macro creates multiple 

instances of the function name - addorned with attributes and does ohter 
things.
(the same header file is compiled in multiple ways) {It simplifies many 
many things 
We really don't want to change that.}

I've tried:

#ifdef DOXYGEN
#define TRAPCALL( X, Y, Z )      X Y Z
#endif

but that does not help, doxygen does not expand #defines.

Doing #ifdef DOXYGEN blocks around hundreds of API function is *NOT* a 
good idea.

Any suggestions?

-Duane.

Re: [Doxygen-develop] RE: PHP and aggregated Objects

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

On Tue, Sep 27, 2005 at 08:17:50AM +0200, S??nke Ruempler wrote:
> Hi,
> 
> Marek Lewczuk <mailto:ma...@le...> wrote on Monday, September 26, 2005 1:51 PM:
> 
> > As you see Doxygen will generate documentation for $someVar, however
> > you cannot put "@var" tag. It seems like a bug, because when you put
> > "@var $someVar" doxygen looks for TestClass::someVar member.
> > 
> > ML
> 
> Yes, that's my experiences, too. May any developer please check this?

You typically should not use @var to try to fool doxygen. In fact you should
not use it at all if the comment block is in front of the variable definition.

If you still think there is a bug (which is certainly possible for PHP) then
please report it using the bug tracker. First describe the bug and then
attach a self-contained example so I can reproduce the problem.

Regards,
  Dimitri

RE: [Doxygen-develop] RE: PHP and aggregated Objects

[<rue...@to...>]

Hi,

Marek Lewczuk <mailto:ma...@le...> wrote on Monday, September 26, =
2005 1:51 PM:

> As you see Doxygen will generate documentation for $someVar, however
> you cannot put "@var" tag. It seems like a bug, because when you put
> "@var $someVar" doxygen looks for TestClass::someVar member.
>=20
> ML

Yes, that's my experiences, too. May any developer please check this?

Best Regards.

Re: [Doxygen-develop] RE: PHP and aggregated Objects

[Marek L. <ma...@le...>]

Sönke Ruempler napisał(a):
> Hi Jens,
> 
> 
> Thx for your answer. I tried several methods inspired from your example, but
> doxygen ignores everything except writing the type between visibilty and the
> variable name. And that's no valid PHP syntax :-/

Try this:

class TestClass {
	
	/**
	 * Brief description.
	 *
	 * Detailed description.
	 */
	public $someVar;
	
	/**
	 * Some method.
	 */
	public static function f2 () {
	}
}


As you see Doxygen will generate documentation for $someVar, however you 
cannot put "@var" tag. It seems like a bug, because when you put "@var 
$someVar" doxygen looks for TestClass::someVar member.

ML

 

RE: [Doxygen-develop] RE: PHP and aggregated Objects

[<rue...@to...>]

Hi Jens,

Jens Miltner <mailto:ju...@ma...> wrote on Monday, September 26, 2005 11:53
AM:

> Hmmh, never tried with any php sources. However, I found that I have
> to move the description of the member variable into a separate line
> in order to get it into the documentation:
> 
> class Test
> {
> public:
>      /*!
>       * @var const foo* bar
>       * \brief a member variable
>       */
>      int    bar;
> };
> 
> (Note that the type difference between the actual declaration
> and the
> documentation is deliberately in this case, because I wanted
> to check
> that the documented type is actually used).
> Maybe using a similar approach may work with php sources?
> 
> HTH,
> </jum>

Thx for your answer. I tried several methods inspired from your example, but
doxygen ignores everything except writing the type between visibilty and the
variable name. And that's no valid PHP syntax :-/

Best regrards.

Re: [Doxygen-develop] RE: PHP and aggregated Objects

[Jens M. <ju...@ma...>]

Am 26.09.2005 um 10:34 schrieb S=F6nke Ruempler:

> Hi,
>
> really no idea about that?

Hmmh, never tried with any php sources. However, I found that I have =20
to move the description of the member variable into a separate line =20
in order to get it into the documentation:

class Test
{
public:
     /*!
      * @var const foo* bar
      * \brief a member variable
      */
     int    bar;
};

(Note that the type difference between the actual declaration and the =20=

documentation is deliberately in this case, because I wanted to check =20=

that the documented type is actually used).
Maybe using a similar approach may work with php sources?

HTH,
</jum>

>
> S=F6nke Ruempler <> wrote on Friday, September 16, 2005 8:20 AM:
>
>
>> Hi,
>>
>> no one answered to my mail on the users list so I hope the
>> developers and insiders may have an answer for me.
>>
>> Here the mail I sent to the users mailing list:
>>
>> S=F6nke Ruempler <mailto:rue...@to...> wrote on
>> Wednesday, September 14, 2005 11:19 AM:
>>
>>
>>> I'm using doxygen (1.4.4-20050815) for documenting my PHP(5) =20
>>> projects
>>> and it works really nice, especially the graphical features.
>>>
>>> But I ran into a little problem. Doxygen has the feature to show
>>> aggregated objects in class members with violett dashed lines. This
>>> does not work right for me with PHP class.
>>>
>>> 1. PHP does not have type hints in class members.
>>>
>>> Example:
>>>
>>> class Blah {
>>>     protected $blah =3D NULL;
>>> }
>>>
>>> So I tried to make it via @var:
>>>
>>> class Blah {
>>>     /**
>>>      * @var    Some_Aggregated_Class    This is an aggregated class
>>>
> .....      */
>
>>>     protected $blah =3D NULL;
>>> }
>>>
>>> But doxygen seems to ignore that. Even the description is not shown.
>>>
>>> Now I tried a little bit further and changed the member declaration
>>> into:
>>>
>>>     protected Some_Aggregated_Class $blah =3D NULL;
>>>
>>> That works for doxygen, it adds "Some_Aggregated_Class" to the
>>> collaboration diagram of "Blah", but it's no valid PHP syntax.
>>>
>>>
>>> 2. Wrong behaviour with static members and constants:
>>>
>>> class Blah {
>>>     static public $var =3D 0;
>>>     const some_constant =3D 'huh';
>>> }
>>>
>>> Doxygen treats them as class types and shows `const' and `static' as
>>> classes in collaboration diagram.
>>>
>>
>>
>> Any help would be appreciated.
>>

[Doxygen-develop] RE: PHP and aggregated Objects

[<rue...@to...>]

Hi,

really no idea about that?

S=F6nke Ruempler <> wrote on Friday, September 16, 2005 8:20 AM:

> Hi,
>=20
> no one answered to my mail on the users list so I hope the
> developers and insiders may have an answer for me.
>=20
> Here the mail I sent to the users mailing list:
>=20
> S=F6nke Ruempler <mailto:rue...@to...> wrote on
> Wednesday, September 14, 2005 11:19 AM:
>=20
>> I'm using doxygen (1.4.4-20050815) for documenting my PHP(5) projects
>> and it works really nice, especially the graphical features.
>>=20
>> But I ran into a little problem. Doxygen has the feature to show
>> aggregated objects in class members with violett dashed lines. This
>> does not work right for me with PHP class.
>>=20
>> 1. PHP does not have type hints in class members.
>>=20
>> Example:
>>=20
>> class Blah {
>> 	protected $blah =3D NULL;
>> }
>>=20
>> So I tried to make it via @var:
>>=20
>> class Blah {
>> 	/**
>> 	 * @var	Some_Aggregated_Class	This is an aggregated class
..... 	 */
>> 	protected $blah =3D NULL;
>> }
>>=20
>> But doxygen seems to ignore that. Even the description is not shown.
>>=20
>> Now I tried a little bit further and changed the member declaration
>> into:=20
>>=20
>> 	protected Some_Aggregated_Class $blah =3D NULL;
>>=20
>> That works for doxygen, it adds "Some_Aggregated_Class" to the
>> collaboration diagram of "Blah", but it's no valid PHP syntax.
>>=20
>>=20
>> 2. Wrong behaviour with static members and constants:
>>=20
>> class Blah {
>> 	static public $var =3D 0;
>> 	const some_constant =3D 'huh';
>> }
>>=20
>> Doxygen treats them as class types and shows `const' and `static' as
>> classes in collaboration diagram.
>=20
>=20
> Any help would be appreciated.

[Doxygen-develop] [PATCH] Fix alphabetical class list

[Frank R. <fra...@gm...>]

If you're using multiple prefixes in IGNORE_PREFIX, the alphabetical
list is basically whack (example:
http://crystalspace3d.org/docs/online/api/classes.php - prefixes are cs
i aws scf). The attached patch will fix the list to be sorted without
the prefix.

(Is this the correct place to send a patch?)

-f.r.

[Doxygen-develop] FW: PHP and aggregated Objects

[<rue...@to...>]

Hi,

no one answered to my mail on the users list so I hope the developers
and insiders may have an answer for me.

Here the mail I sent to the users mailing list:

S=F6nke Ruempler <mailto:rue...@to...> wrote on Wednesday,
September 14, 2005 11:19 AM:

> I'm using doxygen (1.4.4-20050815) for documenting my PHP(5) projects
> and it works really nice, especially the graphical features.=20
>=20
> But I ran into a little problem. Doxygen has the feature to show
> aggregated objects in class members with violett dashed lines. This
> does not work right for me with PHP class. =20
>=20
> 1. PHP does not have type hints in class members.
>=20
> Example:
>=20
> class Blah {
> 	protected $blah =3D NULL;
> }
>=20
> So I tried to make it via @var:
>=20
> class Blah {
> 	/**
> 	 * @var	Some_Aggregated_Class	This is an aggregated class
.....
> 	 */
> 	protected $blah =3D NULL;
> }
>=20
> But doxygen seems to ignore that. Even the description is not shown.
>=20
> Now I tried a little bit further and changed the member declaration
> into:=20
>=20
> 	protected Some_Aggregated_Class $blah =3D NULL;
>=20
> That works for doxygen, it adds "Some_Aggregated_Class" to the
> collaboration diagram of "Blah", but it's no valid PHP syntax.=20
>=20
>=20
> 2. Wrong behaviour with static members and constants:
>=20
> class Blah {
> 	static public $var =3D 0;
> 	const some_constant =3D 'huh';
> }
>=20
> Doxygen treats them as class types and shows `const' and `static' als
> classes in collaboration diagram.=20
=20

Any help would be appreciated.

Nice weekend.

-soenke

Re: [Doxygen-develop] Doxygen appends a dot at the end of a brief description

[Duane E. <dua...@fr...>]

> > I would like to understand why you think this option is needed, i.e.
> > in which case does the dot appear when you do not want it?

> In the generated docs, both functions have a dot at the end of their 
> brief description. But sometimes I have function descriptions without 
> verbs and then the dot looks weird ...

I agree.

The presence or non-presence of a "full-stop" (or period) is a linguistic,
gramatical, or stylistic issue/choice left to the documentor.

In some cases, this may well be a language specific issue.

To have doxygen "fix what it thinks is wrong" - seems wrong to me.

Doxygen is not a grammer checker and automatic grammer fixer.
Doxygen is not a spell-checker with automatic spelling fixer. 

In my mind - doxygen should not become a "punctuation fixer" also.

In subtle ways - having a period/full-stop enforcer smells/sounds very 
much
like an option that does the following:

        Fix my curly brace and indentations to match somebody elses 
standard

Its fine - if there was an option that does something like: 
        Enable warnings about my sloppy sentence structure 
        Enable warnings about my sloppy puncutation 
        Enable warnings about my sloppy spelling

-Duane.

Re: [Doxygen-develop] Doxygen appends a dot at the end of a brief description

[Alex Z. <az...@sy...>]

Dimitri van Heesch wrote:
> On 8/25/05, Alex Zuepke <az...@sy...> wrote:
>=20
>>Hello doxygen developers,
>>
>>I tried to get rid of the implicit dot "." at the end of brief
>>descriptions and found no configuration option to disable this feature
>>... so I added one:
>>
>>BRIEF_APPEND_DOT =3D YES
>>
>>If the BRIEF_APPEND_DOT tag is set to YES (the default) Doxygen will
>>append a dot (".") after each brief description.
>>Note: if OUTPUT_LANGUAGE is set to Chinese, Japanese, or Korean, no dot
>>will be appended.
>>
>>The appended patch is against doxygen 1.4.4 stable.
>>
>>What do you think about this?
>>
>=20
>=20
> I would like to understand why you think this option is needed, i.e.
> in which case does the dot appear when you do not want it?
>=20
> Regards,
>   Dimitri
>=20
>=20

Example:

/** @brief Retrieves value from something special. */
extern int getFoo(const char *bar);

/** @brief This sentence no verb */
extern int getBar(const char *foo);

In the generated docs, both functions have a dot at the end of their=20
brief description. But sometimes I have function descriptions without=20
verbs and then the dot looks weird ...


Best regards,
Alex

--=20
Alexander Z=FCpke                        ale...@sy...
SYSGO AG ~ Am Pfaffenstein 14 ~ 55270 Klein-Winternheim / Germany

Re: [Doxygen-develop] Doxygen appends a dot at the end of a brief description

[Dimitri v. H. <do...@gm...>]

On 8/25/05, Alex Zuepke <az...@sy...> wrote:
> Hello doxygen developers,
>=20
> I tried to get rid of the implicit dot "." at the end of brief
> descriptions and found no configuration option to disable this feature
> ... so I added one:
>=20
> BRIEF_APPEND_DOT =3D YES
>=20
> If the BRIEF_APPEND_DOT tag is set to YES (the default) Doxygen will
> append a dot (".") after each brief description.
> Note: if OUTPUT_LANGUAGE is set to Chinese, Japanese, or Korean, no dot
> will be appended.
>=20
> The appended patch is against doxygen 1.4.4 stable.
>=20
> What do you think about this?
>=20

I would like to understand why you think this option is needed, i.e.
in which case does the dot appear when you do not want it?

Regards,
  Dimitri

[Doxygen-develop] Doxygen appends a dot at the end of a brief description

[Alex Z. <az...@sy...>]

Hello doxygen developers,

I tried to get rid of the implicit dot "." at the end of brief=20
descriptions and found no configuration option to disable this feature=20
... so I added one:

BRIEF_APPEND_DOT =3D YES

If the BRIEF_APPEND_DOT tag is set to YES (the default) Doxygen will=20
append a dot (".") after each brief description.
Note: if OUTPUT_LANGUAGE is set to Chinese, Japanese, or Korean, no dot=20
will be appended.

The appended patch is against doxygen 1.4.4 stable.

What do you think about this?


Best regards,
Alex


--=20
Alexander Z=FCpke                        ale...@sy...
SYSGO AG ~ Am Pfaffenstein 14 ~ 55270 Klein-Winternheim / Germany

Re: [Doxygen-develop] How Doxygen uses graphviz -- links in html graph presentation

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

On Thu, Aug 18, 2005 at 01:27:39PM -0500, Robert G. Ristroph wrote:
> 
> Hi,
> 
>     I would like to use graphviz to make graphs on a web page similar to the way
> doxygen does (but I'm not parsing source code to make them, these are graphs of
> other things).
> 
>     I want the nodes of the graph to be links, the way doxygen does.  I can see
> that in the html output doxygen specifies certain areas of the graph image as
> clickable, but I was wondering where in the source code of doxygen it figures
> out what coordinates are associated with each node.
> 
>     I would like to look at doxygen to see how it is done, but I am having
> trouble finding it.  If anyone could tell me where that functionality is in the
> code, or how to achieve that result another way, or another example to look at,
> I would really appreciate it.

The easiest way to see how doxygen runs dot is to use the "-d ExtCmd" 
debug option when running doxygen from the command line.

In short doxygen uses -Timap to generate a map file along with the image.
Note that this is a server side image map, which doxygen then translates to
a client side image map which is embedded in the HTML page. IIRC recent
versions of dot also support generating the client side maps directly.

Regards,
  Dimitri

[Doxygen-develop] How Doxygen uses graphviz -- links in html graph presentation

[Robert G. R. <rri...@ai...>]

Hi,

    I would like to use graphviz to make graphs on a web page similar to the way
doxygen does (but I'm not parsing source code to make them, these are graphs of
other things).

    I want the nodes of the graph to be links, the way doxygen does.  I can see
that in the html output doxygen specifies certain areas of the graph image as
clickable, but I was wondering where in the source code of doxygen it figures
out what coordinates are associated with each node.

    I would like to look at doxygen to see how it is done, but I am having
trouble finding it.  If anyone could tell me where that functionality is in the
code, or how to achieve that result another way, or another example to look at,
I would really appreciate it.

    Thanks in advance for any help you can offer me.

--Rob

-- 
Robert G. Ristroph
Airlink Systems
rri...@ai...
(512) 231-1240 x103





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

RE: [Doxygen-develop] Firefox performance

[Nikolay M. <N.M...@te...>]

It turned out they were not aware of the problem. I have created a new
bug and the mozilla people seem to have responded by creating 3 new bugs
to fix it:
https://bugzilla.mozilla.org/show_bug.cgi?id=3D304683

It might be a while before they fix it....=20

-----Original Message-----
From: Dimitri van Heesch [mailto:di...@st...]=20
Sent: 11 August 2005 3:07 PM
To: Nikolay Metchev
Cc: dox...@li...
Subject: Re: [Doxygen-develop] Firefox performance

On Thu, Aug 11, 2005 at 02:23:04PM +0100, Nikolay Metchev wrote:
> Dimitri,
>=20
> I am using the latest version of Doxygen 1.4.4 and the latest version=20
> of Firefox 1.0.6 in Windows XP SP2. And I am still finding that IE=20
> (version
> 6) outperforms firefox by far. Do you have any clue why this is? This=20
> is only really apparent on a large project.

I don't, so this may be seen as a different mozilla bug.

All I know is that the tree.html file can become quite large (the one
for doxygen own sources is already 300k), so this takes time to read and
process.=20
Maybe IE sees that all sections are hidden initially and does less
processing in this case, but that's is just wild speculation...

I can't think of anything to make this faster however.

Regards,
  Dimitri

[Doxygen-develop] A way and place to modify internal program model

[Peter A. K. <ke...@ma...>]

Greetings, doxygen developers!
Pleased to meet you here :) I'm new to this list, so please accept my excuses 
for potentially stupid questions :)
So, here's the thing that brought me here. I develop C++ and I like doxygen 
much for a pretty nice UML-like models it draws (especially with dot). But 
C++ modeling lacks one very important feature - consider following code:

class A { /* ... */};
typedef A A_alias;
class B { A_alias a; };

The collaboration diagram for B will not represent any usage of A, while it is 
obvious on the language side. While one might argue against aliasing, it is 
quite common while using STL, e.g.:

#include <vector>
class A { /* ... */ };
class B
{
	typedef vector<A> storage_t;
	storage_t storage;
};

So some time ago I implemented this feature by adding additional pass over 
entire model just after model is finished, but before any output generation. 
For each typedef that pass created a class with the same name and added a 
usage link to the real type. Unfortunately my implementation was so weird 
that I erased all the code I've written as soon as I made it up.

So, what I want to say is that this is quite handy feature that will help 
reverse analyzing a lot. And I would like to provide consistent 
implementation, but for that purpose I'll possibly require a bit of your 
attention. So, could you please point me the place to put this kind of code? 
I suppose parsing phase is more appropriate than additional loop, and I think 
that it might be more consistent way to extend typedef representation a bit 
and then extend typedef interpretation by graph subsystem.

Well, finally I am looking forward to receiving any guidelines from you.
Thanks in advance :)

-- 
Best Regards,
Peter A. Kerzum

Re: [Doxygen-develop] Firefox performance

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

On Thu, Aug 11, 2005 at 02:23:04PM +0100, Nikolay Metchev wrote:
> Dimitri,
> 
> I am using the latest version of Doxygen 1.4.4 and the latest version of
> Firefox 1.0.6 in Windows XP SP2. And I am still finding that IE (version
> 6) outperforms firefox by far. Do you have any clue why this is? This is
> only really apparent on a large project. 

I don't, so this may be seen as a different mozilla bug.

All I know is that the tree.html file can become quite large (the one for
doxygen own sources is already 300k), so this takes time to read and process. 
Maybe IE sees that all sections are hidden initially and does less 
processing in this case, but that's is just wild speculation...

I can't think of anything to make this faster however.

Regards,
  Dimitri

RE: [Doxygen-develop] Firefox performance

[Nikolay M. <N.M...@te...>]

Dimitri,

I am using the latest version of Doxygen 1.4.4 and the latest version of
Firefox 1.0.6 in Windows XP SP2. And I am still finding that IE (version
6) outperforms firefox by far. Do you have any clue why this is? This is
only really apparent on a large project.=20

Nikolay

-----Original Message-----
From: Dimitri van Heesch [mailto:di...@st...]=20
Sent: 11 August 2005 2:16 PM
To: Nikolay Metchev
Cc: dox...@li...
Subject: Re: [Doxygen-develop] Firefox performance

On Tue, Aug 02, 2005 at 10:31:33AM +0100, Nikolay Metchev wrote:
> Is there anything that could be done to the HTML output of doxygen to=20
> improve performance on Firefox?
> =20
> On projects with lots of source code doxygen seems to generate=20
> JavaScript which makes Firefox struggle.
> =20
> Here is the bug report in mozilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D218308

Interesting!

> That bug report suggests one improvement comment 6. But perhaps a=20
> rework of the html is more desirable?

For quite some time (i.e more than 2 years) doxygen uses a completely
different way of producing the tree view. Doxygen now generates all
output in HTML form and uses a single Javascript function to toggle
opening and closing of folders. So any performance issues mentioned in
this bug report do not apply anymore!

Regards,
  Dimitri

Re: [Doxygen-develop] Firefox performance

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

On Tue, Aug 02, 2005 at 10:31:33AM +0100, Nikolay Metchev wrote:
> Is there anything that could be done to the HTML output of doxygen to
> improve performance on Firefox?
>  
> On projects with lots of source code doxygen seems to generate
> JavaScript which makes Firefox struggle.
>  
> Here is the bug report in mozilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=218308

Interesting!

> That bug report suggests one improvement comment 6. But perhaps a rework
> of the html is more desirable?

For quite some time (i.e more than 2 years) doxygen uses a completely 
different way of producing the tree view. Doxygen now generates all output 
in HTML form and uses a single Javascript function to toggle opening and 
closing of folders. So any performance issues mentioned in this bug
report do not apply anymore!

Regards,
  Dimitri