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

[Doxygen-develop] Windows binaries available for Doxygen-1.3.6-20040307 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_20040307.zip.=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

P.S. The translator report can be found in the file=20
     like tr20040307.zip.
  =20
--=20
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] fixing qtools.dsp

[kemal a. <as...@cl...>]

as i tried to compile doxygen-1.3.6.src.tar.gz on windows using the
projects in the wintool directory.but  with the file as in the archive i
kept getting an error message until i found out the the file QGCache.CPP
is missing as a source in the project qtools.dsp. i have the corrected
dsp file. let me know if it can be helpfull. i would be honored tohave
contributed even this very very small piece to the so widly spread
project doxigen.
Regards.
Kemal

[Doxygen-develop] documenting template parameters.

[Hagen M. <mai...@st...>]

Hi List.

I would like to add the TODO-list item #29 which should allow documenting
template parameters via the keyword @tparam or in place. This is just the
announcement I have not done a single line for it, so pls go on and try
and stop I you must. I would like to add this feature because gtkmm
documentation may be in need of it in the future :).

Any input is aprreciated and you are welcome to request features applying
to this task.

Regards,

Hagen

PS: Pls also tell me where I should send my patches. Bugzilla seems the
right spot, is it?

Re: [Doxygen-develop] Q_PROPERTY property support

[Marcus <ma...@my...>]

Great. It would be especially helpful if support for Q_PROPERTY were included 
in the XML output. Right now I'm using a crude hack where I define a macro 
for Q_PROPERTY to make it look like a method declaration...


On Tuesday 02 March 2004 9:06 pm, Dimitri van Heesch wrote:
> On Fri, Feb 06, 2004 at 10:25:19PM -0500, Marcus wrote:
> > I see that support for Q_PROPERTY is on the TODO list. Is anyone working
> > on it? I'm moving from a custom-built C++ header parser to Doxygen, and I
> > am really missing support for Q_PROPERTY.
>
> I'm now working on this. Should be in the next release.

Re: [Doxygen-develop] Q_PROPERTY property support

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

On Fri, Feb 06, 2004 at 10:25:19PM -0500, Marcus wrote:
> I see that support for Q_PROPERTY is on the TODO list. Is anyone working on 
> it? I'm moving from a custom-built C++ header parser to Doxygen, and I am 
> really missing support for Q_PROPERTY.

I'm now working on this. Should be in the next release.

Regards,
  Dimitri

[Doxygen-develop] Info on the status of the language translators (February 24, 2004)

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

Info on the status of the language translators (February 24, 2004)=20

Related to the Doxygen 1.3.6-20040222 in CVS. Posted to
doxygen-develop, copied to doxygen-users. The previous
report was dated December 16, 2003.

ATTENTION: Since the Doxygen 1.3.6-20040222, the=20
translator_report.txt is generated by the new translator.py
script that extracts also some information that was collected
manually in the past. The most general things are placed
at the beginning of the report. The full translator_report.txt=20
is stored at http://doxygen.sourceforge.net/dl/doxygen-1.3-cvs/=20
as tr2004MMDD.zip where MMDD is replaced by the month and day.

The following text is the head of the translator_report.txt.=20
My comments follow after:

=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
(1.3.6-20040222)

Doxygen supports the following 28 languages (sorted alphabetically):

Brazilian Portuguese, Catalan, Chinese, Chinese Traditional, Croatian,
Czech, Danish, Dutch, English, Finnish, French, German, Greek,
Hungarian, Italian, Japanese (+En), Korean (+En), Norwegian, Polish,
Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
Swedish, and Ukrainian.

Of them, 15 translators are up-to-date, 13 translators are based on
some adapter class, and 2 are English based.

----------------------------------------------------------------------
The following translator classes are up-to-date (sorted
alphabetically). This means that they derive from the Translator class
and they implement all 194 of the required methods. Anyway, there
still may be some details listed even for them. Please, see the
details for them:

  TranslatorBrazilian
  TranslatorChinesetraditional
  TranslatorCroatian
  TranslatorCzech
  TranslatorDanish
  TranslatorDutch
  TranslatorEnglish
  TranslatorFrench
  TranslatorGerman
  TranslatorHungarian
  TranslatorItalian
  TranslatorKorean
  TranslatorRussian
  TranslatorSerbian
  TranslatorSpanish -- Change the base class to Translator.

----------------------------------------------------------------------
The following translator classes need some maintenance (the most
obsolete at the end). The other info shows the estimation of Doxygen
version when the class was last updated and number of methods that
must be implemented to become up-to-date:

  TranslatorSwedish               1.3.3 	 4 methods to implement
  TranslatorPortuguese            1.3.3 	 4 methods to implement
  TranslatorJapanese              1.3.3 	 4 methods to implement
  TranslatorPolish                1.3   	11 methods to implement
  TranslatorSlovak                1.2.18	13 methods to implement
  TranslatorCatalan               1.2.17	14 methods to implement
  TranslatorSlovene               1.2.16	15 methods to implement
  TranslatorRomanian              1.2.16	15 methods to implement
  TranslatorChinese               1.2.13	17 methods to implement
  TranslatorUkrainian             1.2.11	18 methods to implement
  TranslatorGreek                 1.2.11	18 methods to implement
  TranslatorNorwegian             1.2.2 	44 methods to implement
  TranslatorFinnish               obsolete	91 methods to implement

Note: The TranslatorAdapter_1_2_1 class is not used and can be removed.

----------------------------------------------------------------------
The following translator classes derive directly from the
TranslatorEnglish. The class identifier has the suffix 'En' that says
that this is intentional. Usually, there is also a non-English based
version of the translator for the language:

  TranslatorJapaneseEn	implements 5 methods
  TranslatorKoreanEn	implements 5 methods
=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=


Now, my (human) comments:

The Hungarian translator did a big leap from very old to=20
up-to-date status since the December 2003. Thanks
go to the new maintainer, Akos Kiss. Great job.

Also, the Norwegian maintainer, Lars Erik Jordet,=20
was heard that the Norwegian translator will be updated
soon.

But...
  -----------------------------------------------
  We still have not found new Finnish maintainer. =20
  The translator became extremely obsolete, and=20
  it seems that the original maintainer is not
  in touch with doxygen anymore.
  -----------------------------------------------

For the Spanish maintainer, see the translator report.
The script detected that you did a good job and reached=20
the up-to-date status. The only thing you forgot to do
was to derive directly from the Translator class --
no need to use the TranslatorAdapter_x_y_z.

For the other maintainers, let's the goal is to update
your languages at least to the 1.3 status. The current
Doxygen version is 1.3.6.

Finally, my thanks to all active language maintainers.

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

[Doxygen-develop] Windows binaries available for Doxygen-1.3.6-20040222 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.
=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
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] manonly patch

[Carsten S. <ca...@ww...>]

Dear doxygen developers,

I'm a very fond user of doxygen, I use it for all my documentation needs. 
However, I recently discovered while writing a man page, through doxygen, 
that it didn't do exactly what I wanted it to do. I wanted to make an 
underline of my applications name, and found that neither the html tag <u> or 
an equivalent doxygen tag existed. At this point I thought about adding 
support for <u> in doxygen, but I soon discovered while continuing writing my 
man page that I at times needed more specific nroff code, so I looked for a 
manonly option. This doxygen code didn't exist, and I couldn't think of any 
reason why it shouldn't, so I added it to my code, and made a patch (Html 
documentation included). Unfortunately my code wasn't the newest 1.3.6 
release but 1.3.4, however, I've checked the patch with 1.3.6 under cygwin 
and it seems to work.

Regards,
  Carsten Stiborg

--
Open WebMail Project (http://openwebmail.org)

Re: [Doxygen-develop] Doxygen XML Schema life expectancy

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

On Mon, Feb 16, 2004 at 09:15:37AM +0000, C Williams wrote:
> Hello to all,
> 
> I'm doing preliminary research on the development of a
> rendering pipeline to output custom documentation
> using Doxygen's XML output (in a similar manner to
> that used for Xerces{xml.apache.org} and
> OpenTop{elcel.com}).
> 
> I was wondering how 'stable' the current Schema(s)
> are: i.e. How 'cast-in-iron' are they?; and what is
> the likelihood that they might be restructured in the
> near future?
> 
> The documentation points out that the XML support is
> still under development, and also that XML will be
> used as an intermediate language in future versions.
> 
> Small alterations (such as the attribute change from
> 'id' to 'refid') are no problem, but it would be
> useful to know if a major overhaul was looking likely
> (not that it necessarily needs it).
> 
> Any information would be gratefully received, and many
> thanks also for this phenomenal tool.

I do not intent to do any major restructuring of the XML
output (unless there is a very very good reason for it,
for instance that the current structure is unusuable, but I
do not expect that to happen). So you can assume the
XML output to be stable as it is now.

Regards,
  Dimitri

[Doxygen-develop] Doxygen XML Schema life expectancy

[<yic...@ya...>]

Hello to all,

I'm doing preliminary research on the development of a
rendering pipeline to output custom documentation
using Doxygen's XML output (in a similar manner to
that used for Xerces{xml.apache.org} and
OpenTop{elcel.com}).

I was wondering how 'stable' the current Schema(s)
are: i.e. How 'cast-in-iron' are they?; and what is
the likelihood that they might be restructured in the
near future?

The documentation points out that the XML support is
still under development, and also that XML will be
used as an intermediate language in future versions.

Small alterations (such as the attribute change from
'id' to 'refid') are no problem, but it would be
useful to know if a major overhaul was looking likely
(not that it necessarily needs it).

Any information would be gratefully received, and many
thanks also for this phenomenal tool.

C Williams


	
	
		
___________________________________________________________
BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk

[Doxygen-develop] Q_PROPERTY property support

[Marcus <ma...@my...>]

I see that support for Q_PROPERTY is on the TODO list. Is anyone working on 
it? I'm moving from a custom-built C++ header parser to Doxygen, and I am 
really missing support for Q_PROPERTY.

[Doxygen-develop] Windows binaries available for Doxygen-1.3.5-20040125

[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. For example, the file

  doxygen_win32_20040125.zip

is related to Doxygen-1.3.5-20040125 (the version
published in 25th January 2004). When unzipping
the file, the Doxygen-1.3.5-20040125 subdirectory
is created in the working directory. Since the mentioned
date, the translator_report.txt is included inside=20
the subdirectory. The binaries (doxygen.exe and=20
doxytag.exe) are placed in the bin subdirectory.
=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
--=20
Petr Prikryl (prikrylp at skil dot cz)

[Doxygen-develop] configure patch for QTDIR

[Erik Z. <ze...@ma...>]

Configure is not finding the proper QTDIR when the environment variable is
properly set.

On Redhat 9, there are directories for both qt-3.1 and qt-2.3.1, but
configure only finds qt2 which is a sym link to qt-2.3.1.

The attached diff changes the behavior to assume that the QTDIR environment
variable is correctly set and only searches if it's not actually set.

Erik

-- 
*******************************************
Dr. Erik Zeek
Postdoctoral Fellow
School of Physics
Georgia Institute of Technology
Atlanta, GA  30332-0430

Tel: 404-385-1034
FAX: 425-988-9013

Web:   http://www.physics.gatech.edu/gcuo/
Email: mailto:ze...@ma...
 

[Doxygen-develop] Confused RTF Output

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

I have customized the RTF style sheet to try to map to my corporate Word
styles.  The problem is that Doxygen does not use UNIQUE styles.  For
instance:

 

Body Text may be:

normal level 1 paragraph style (text)

an Include file listing (with Courier font)

an inlined name of a function or parameter (with Bold, character based)

 

            List Continue 1 may be:

                        Level 2 text paragraph style

                        "Parameter", "Returns", etc.  heading (with Bold,
character based)

                        an inlined name of a function or parameter  (with
Bold, character based)

 

The styles should be laid out so that an element ALWAYS maps to a unique
style.  Styles SHOULD NOT be modified to handle a second function.
Suggested layout, with associated text styles (shown without space before or
after):

 

Head 1 = Major Topic

Body Text 0

Bullet 0

List 0

Head 2 = Major Sub-Topic

Body Text 0

Bullet 0

List 0

Head 3 = Class, Structure, or Union  Reference ( = current Head 2)

Body Text 0

Bullet 0

List 0

Head 4 = "Detailed Description" "Public ....", "Private ....", "Member
Function Documentation", etc

Body Text 1

Bullet 1

List 1

Head 5 = "See also", Constructor & Destructor Documentation", etc.

Body Text 2

Bullet 2

List 2

Head 6 = Member Function

Body Text 3

Bullet 3

List 3

Head 7 = "Parameters", "Returns", "Since", etc

Body Text 4

Bullet 4

List 4

 

It would be HIGHLY beneficial (and would avoid many other problems) if
Doxygen permitted each style in the RTF Style sheet to be directly mapped to
a SET of specific text patterns and/or <keyword>+<pattern>.  This
could/should be in the form of a text file and/or GUI to build the text
file.  The user could then map "Parameters^p", "Returns^p", and/or "Goofy^t"
to Heading 7. Heading 7 should then assert that the next text / bullet text
/ list text would assume the level of 4 until a different level was asserted
by a header or an override.

 

Regards,

Larry Randall

******* Documentation

 

[Doxygen-develop] doxygen.spec file

[Erik Z. <ze...@ma...>]

The doxygen.spec file is currently empty on the CVS server.  Is this
intentional?

Erik

-- 
*******************************************
Dr. Erik Zeek
Postdoctoral Fellow
School of Physics
Georgia Institute of Technology
Atlanta, GA  30332-0430

Tel: 404-385-1034
FAX: 425-988-9013

Web:   http://www.physics.gatech.edu/gcuo/
Email: mailto:ze...@ma...
 

[Doxygen-develop] documenting other filetypes

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

hi all,

I would like to start a discussion about ideas of "how to document other file
types".

I have a project where files like a dtd and lots of xml, xsl files are important
for the developer as well. Other projects have config files or scripts.

I helped myself a bit by using a mini perl wrapper which at least reformats the
xml-comments so thatthey look like /** ... */ comments. This way we can document
the files them selfts and reference them.
For the dtd I have tried a hack to even convert the content to enums, structs
and functions. This work a little, but is ugly as the documentation (see
http://141.57.8.37/ensonic/gitk-docs/group__gitkcoredtd.html) is showing the in
this representation then.

Dimitri, how much separarated is the parser for c-style files. The goal is that
one could add a nother class and register the class together with
  * extension (that causes the class to bee invoked)
  * symbol-list it generated (e.g. entities, elements and attributes for a dtd)
Obviously there are many problems on the way to this functionallity, so lets
collect them and provide solutions, step-by-step.

Dimitri, it would be very kind, if you could tell us, wheter you would like to
support other file types in the future or if not.

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
===-=-=--=---=---------------------------------- - - -  -    -

RE: [Doxygen-develop] xml & inner page

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

	Hi again!
	Yet another problem with xml \page...
	Example 1.
/*! \page page1 page1
  page1=20
*/
	HTML output ok.
	XML output generate a warning=20
.../page.doc:3: Warning: included file page1 is not found. Check your =
EXAMPLE_PATH
	xmlgen.cpp: generateXMLForPage
...
	  writeXMLDocBlock(t,pd->docFile(),pd->docLine(),pd,0,
      pd->documentation()+"\n\\include "+pd->name());
Is +"\n\\include "+pd->name() valid for examples only?

RE: [Doxygen-develop] \page and \group

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

	Hi!
	a) Has \page command generate separate file or all pages text combine =
to a group text? At XML, at HTML?
	b) "\ref page" generate reference to a page or to owner group? At XML, =
at HTML?

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++	=
Example 1. page.doc
/*! \defgroup G1 group1
 * \{
 */

/*! \page page1 page1
  page1 \ref page2
*/

/*! \page page2 page2
  page2 \ref page1
*/

/*!
 \}
 */

	HTML: Documentation for page1 and page2 generates in ++++GROUP+++ file =
group___g1.html. Why? I can write text to group file at \group command. =
I'd like to write separate page.
	XML: Documentation for page1 and page2 generates ++++2+++ files + group =
file: group___g1_page1.xml, group___g1_page2.xml, group___g1.xml. Ok.

	HTML: \ref looks like reference to ++++GROUP++++ ( <a class=3D"el" =
href=3D"group___g1.html">page1</a>. See comment before, but it works.
	XML: \ref looks like reference to ++++GROUP++++ (<ref refid=3D"page2" =
kindref=3D"compound">page2</ref>). Fail(?) 3 files.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=09
	Example 2. page.doc:
/*! \page page1 page1
  page1 \ref page2
*/

/*! \page page2 page2
  page2 \ref page1
*/
	HTML:	Documentation for page1 and page2 generates in +++2+++ files: =
page1.html page2.html. Ok.
	XML: Documentation for page1 and page2 generates in +++2+++ files:=20
page1.xml page2.xml. Ok.

	HTML: \ref looks like <a class=3D"anchor" name=3D"page2">page2</a>. Ok.
	XML: <ref refid=3D"page2" kindref=3D"compound">page2</ref>. Ok.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

	I don't use HTML output :), I try html to understand what output is =
valid, but not understand a thing.

[Doxygen-develop] New feature request topic id

[kemal a. <as...@cl...>]

in *.chm files there is a way to put topic ids using [MAP] in the input
files for the help workshop. Topic id are very usefull when writting
help files to a application on windows as it is the key to integrate
help to a button for example. i think if in some ways it is possible to
change how doxygen work so when it documents function  it can add a
topic id to the . i hope this is clear to explain the new functionality
i am looking for otherwise just let me know.if it is already possible to
do it. i would like to know too.

thanks
Kemal

Re: [Doxygen-develop] New feature request, the '+=' assigment (and Include directive?)

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

On Thu, Jan 08, 2004 at 04:52:32PM -0700, Marcelo Matus wrote:
[snip]
> 
> What I can't work around is the lack of the += assigment, and therefore,
> right now, I have to keep repeated information in several places: each 
> library .cfg
> file and in the global .cfg one, which is ugly and dangerous.

Why do you assume the += operation is not supported?
It is! and the documentation even says so ;-)

See http://www.stack.nl/~dimitri/doxygen/config.html

"For options that take a list as their argument, the += operator can 
 be used instead of = to append new values to the list."

Regards,
  Dimitri

[Doxygen-develop] New feature request, the '+=' assigment (and Include directive?)

[Marcelo M. <mm...@di...>]

Hello:

I am using doxygen, and is great!, but I am getting the idea
that a feature like the '+=' assigment will make it even better,
like in:

-- myfile.cfg --
.....

INPUT  += /home/mmatus/cvs/modules2/oss
FILE_PATTERNS  +=  oss.doc
....
-- myfile.cfg --


let me explain the problem first:

I have several big libraries that are related,
but say we have just two: 'bss' and 'oss'

Most of the time, when writting or testing
the documentation I compile only the
library I am interesting on, and use the 'tag'
doxygen features for the references to the
other libraries, and then I have the following files


base.cfg -> allmost full doxygen.cfg file, but with no INPUT definition
oss_i.cfg   -> defines  the INPUT and FILE_PATTERNS for 'oss'
bss_i.cfg   -> defines  the INPUT and FILE_PATTERNS for 'bss'


So, to process the documentation for each library, I just do

  cat base.cfg oss_i.cfg | doxygen -

or

  cat base.cfg bss_i.cfg | doxygen -

This is fast for development.

But in some moment I will have to generate the documentation for
all the libraries  togheter, something like

   cat base.cfg bss_i.cfg oss_i.cfg | doxygen -

and then using the += assigment will be really handy because if I define

-- oss_i.cfg --
INPUT  += /home/mmatus/cvs/modules2/oss
FILE_PATTERNS  +=  oss.doc ...
-- oss_i.cfg --

then I can add as many libraries as I want resuing the local INPUT and
FILE_PATTERNS variables defined in each library cfg file, which will be
contatenated to generate the global INPUT and FILE_PATTERNS variables
needed to compile the whole thing at once.

And this example then introduce us also to the other request, which I guess
could be much harder: the include directive.

As you see before, I am splitting the .cfg files, and then instead of 
using the 'cat'
command, it will be more natural to have:

--- bss.cfg ---
#include "base.cfg"
#include "bss_i.cfg"
TAGFILES = ...
OUTPUT =...
--- bss.cfg ---

--- oss.cfg ---
#include "base.cfg"
#include "oss_i.cfg"
TAGFILES = ...
OUTPUT =...
--- oss.cfg ---

--- all_libraries.cfg ---
#include "base.cfg"
#include "bss_i.cfg"
#include "oss_i.cfg"
OUTPUT =...
--- all_libraries.cfg ---

then, I could process quick individual library .cfg files (bss.cfg, 
oss.cfg),
using TAGFILES as needed, and from time to time, process the entire
whole thing at once using the 'all_libraries.cfg' file.

But of course, since I still can use 'cat | doxygen -', that is just an 
improvement
in usability.

What I can't work around is the lack of the += assigment, and therefore,
right now, I have to keep repeated information in several places: each 
library .cfg
file and in the global .cfg one, which is ugly and dangerous.

Marcelo

Re: [Doxygen-develop] patches

[Akos K. <ak...@us...>]

Hi,

On Thursday 08 January 2004 19.17, Dimitri van Heesch wrote:
> > 2003-12-12  Akos Kiss  <ak...@us...>
> >
> >         [...]
> >
> >         * src/config.l (HTML_SHOW_LOGO): New configuration option.
> >         * doc/config.doc (HTML_SHOW_LOGO): Document it.
> >         * src/htmlgen.cpp (HtmlGenerator::init, writePageFooter): Use it.
>
> This will not be added. There is an easy alternative (using a custom
> footer), which does not justify Yet Another Option IMHO. I do agree that
> the color-scheme of the logo can be improved.

allow me to disagree. My solution is portable across languages, since you 
don't have to change the footer file when you change the output language. 
(But of course the ultimate decision is yours.)

Regards,
Akos

Re: [Doxygen-develop] to compile on windows

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

On Thu, Jan 08, 2004 at 11:22:29AM +0100, kemal asad wrote:
> to get a better undrstanding of how doxygen generates *.chm files, i
> would like to compile the latest doxygen on windows, what will i need to
> install , i just got a new fresh machine. just with w2k, what should i
> install i have VC6.0.

See http://www.doxygen.org/install.html#install_src_windows

Regards,
  Dimitri

Re: [Doxygen-develop] patches

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

On Tue, Jan 06, 2004 at 11:55:47AM +0100, Akos Kiss wrote:
> Hi,
> 
> I'm glad to see that most of my patches got into the CVS, but there are two
> of them for which I got no feedback and are not in the CVS. Any chance of
> inserting them into the sources?
> 
> Regards,
> Akos
> 
> 
> 2003-12-15  Akos Kiss  <ak...@us...>
> 
>         * classdef.cpp (ClassDef::writeDocumentation,
>         ClassDef::writeMemberList): File title and page title made the same.
>         * filedef.cpp (FileDef::writeDocumentation): Likewise.
>         * namespacedef.cpp (NamespaceDef::writeDocumentation): Likewise.

I still have to evaluate this one.

> 
> 2003-12-12  Akos Kiss  <ak...@us...>
> 
>         [...]
> 
>         * src/config.l (HTML_SHOW_LOGO): New configuration option.
>         * doc/config.doc (HTML_SHOW_LOGO): Document it.
>         * src/htmlgen.cpp (HtmlGenerator::init, writePageFooter): Use it.
> 

This will not be added. There is an easy alternative (using a custom
footer), which does not justify Yet Another Option IMHO. I do agree that
the color-scheme of the logo can be improved.

Regards,
  Dimitri

[Doxygen-develop] to compile on windows

[kemal a. <as...@cl...>]

to get a better undrstanding of how doxygen generates *.chm files, i
would like to compile the latest doxygen on windows, what will i need to
install , i just got a new fresh machine. just with w2k, what should i
install i have VC6.0.
thanks
Kemal