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

Re: [Doxygen-develop] Morirz First Releas on sourceforge.net

[<Eck...@t-...>]

Dear Mr Dodge.

Sorry but I'm a newbe in opensource and sourcefaorge.

The moritz-unix doesn't mean that this is a unix-project. Sourceforge 
asked for an unique unix-name for the project. I didn't really 
understand what they want and I took the prefix unix because I don't use 
this in any other keyword of the project. Today I know it was a big 
failure of mine and I will ask if this can be changed.


To build Moritz just the following files has to be used:

src\
    diverse\
            c\
              KeyListSet.cpp
              MoritzHelp.cpp
              String_imp.cpp
            h\        
              KeyListSet.h
              MoritzHelp.h
              String_imp.h
    Moritz\
           c\
             main.cpp
    xmlblock\
             c\
               xmlBlock.cpp
             h\        
               xmlBlock.h
    xmlvisitor\
               c\
                 tool_gennsd.cpp 
                 tool_nsdanl.cpp 
                 xmlVisitor.cpp 
                 xmlvst_fileanl.cpp
                 xmlvst_fncbdy.cpp
                 xmlvst_fnchd.cpp
                 xmlvst_gennsd.cpp
               h\        
                 tool_gennsd.cpp 
                 tool_nsdanl.cpp 
                 xmlVisitor.cpp 
                 xmlvst_fileanl.cpp
                 xmlvst_fncbdy.cpp
                 xmlvst_fnchd.cpp
                 xmlvst_gennsd.cpp

Don't use the other sources especially those in the wx-directories. This 
files are necessary for the wizard I want to write in the next time.
(Sorry for the confusion they corse)

This are the standard include-files of c/c++ used by Moritz:

   map.h
   set.h
   vector.h
   list.h
   fstream.h
   string.h
   sstream.h
   sys/stat.h


Since Moritz is a common console-application no special libraries are 
necessary.

I'm not very familiar with make-files and use an ide (DevC++, 
Code-Blocks, MinGW Developer-Studio, ...) to manage the project and the 
compile-process.
I don't use special compiler-options to optimize the program. For me the 
only steps to compile the sources is to add them into the ide-project, 
add the 3 h-paths and start the compilation.

I hope this will help you.




Dave Dodge schrieb:
> On Tue, May 30, 2006 at 10:05:55PM +0200, Eck...@t-... wrote:
>   
>> You can download it under : "www.sourceforge.net/projects/moritz-unix"
>>     
>
> Is this supposed to be usable on Unix systems yet?  It's a little
> confusing because the project name is "moritz-unix" but all of the
> released files are listed as "win32".  For example I took a quick look
> at the source files and didn't see any Makefiles or build instructions
> anywhere.
>
>                                                   -Dave Dodge
>
>
>   

Re: [Doxygen-develop] Morirz First Releas on sourceforge.net

[Dave D. <do...@do...>]

On Tue, May 30, 2006 at 10:05:55PM +0200, Eck...@t-... wrote:
> You can download it under : "www.sourceforge.net/projects/moritz-unix"

Is this supposed to be usable on Unix systems yet?  It's a little
confusing because the project name is "moritz-unix" but all of the
released files are listed as "win32".  For example I took a quick look
at the source files and didn't see any Makefiles or build instructions
anywhere.

                                                  -Dave Dodge

[Doxygen-develop] Morirz First Releas on sourceforge.net

[<Eck...@t-...>]

Hello Everyone.

I did it now. Moritz my  nassi-shneiderman generator for doxygen is 
uploaded as first test-release.
You can download it under : "www.sourceforge.net/projects/moritz-unix"

You will find 5 files:
1. distribution-zip (contains a file-system with an test-project)
2. user-documentation 3. developer-documentation (user-doc + source-doc)
4. source-zip
5. readme.txt

I hope my English was good enough for writing a useful documentation. If 
not don't hesitate to ask me.

Please find some time to test the tool.

Kind regards,
                      Eckard Klotz.

[Doxygen-develop] PATCH: Support for caller graph and modify hyperlink behaviour for references/referenced by

[Daniel a. Mary-B. S. <jac...@ya...>]

Hi

Please find attached a patch (based on yesterday's
tarball) that adds the following features:

1) Caller graphs (inverse call graphs) are enabled
with the CALLER_GRAPH tag (defaults to NO) and
/callergraph commands and behave in the same way as
call graphs.

2) The REFERENCES_LINK_SOURCE tag (defaults to YES)
can be used to modify the behaviour of the 'referenced
by' and 'references' lists such that they if the tag
is set to NO, then links to functions will go to the
documentation rather than the source.  Default
behaviour remains the same.

Hope that this is in the expected format for rapid
inclusion.

Daniel




		
___________________________________________________________ 
Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com

[Doxygen-develop] nassi-shneidermann generator for doxygen

[<Eck...@t-...>]

Dear Mr. Van Heesch.=20
=20
My name is Eckard Klotz. I sent you an e-mail last year (16.12.2005 =
"add-on for DoxyGen") to introduce you my "add-on" project for Doxygen =
named "Moritz". I hope you received it and remember.=20

Since that time I tried to contact you. But you didn't answer. I'm not =
disappointed about this. I think you are a employee like me  and it is =
hard for you to find the time to play nanny for a project like mine.

But in the last days you seam to be active again and so I hope you will =
find the time to give me a little acknowledge.=20

=20

As I wrote before Moritz is an additional tool like dot and it generates =
nassi-shneiderman diagrams of the functions or methods of a c/c++ =
source. Moritz could be controlled by special comments and =
configuration-files (like Doxygen). The file-format of the diagrams is =
htm, so they can be added to the Doxygen-output via htmlinclude.

=20

I've sent some zip.files with an older version (seen from today) of =
Moritz and a documentation with some included diagrams. I hope you've =
received the files are able to take a look to the diagrams.=20

=20

At the moment I'm thinking about publishing Moritz via sourceforge as =
open-source and freeware under GPL. I want give you the chance to =
propose some changes to increase the compatibility to Doxygen. So the =
question is how to send you an newer version, if you are not able to =
open my zip-files before I opened the sourceforge-project.=20

=20

Best regards,

                      Eckard Klotz.

Re: [Doxygen-develop] Parser for VB.NET - namespaces

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

On 4/12/06, James Bursa <jam...@mi...> wrote:
>
> I have started implementing support for VB.NET for Doxygen. The patch and
> scanner for this are attached. Would there be interest in including this
> in Doxygen?


I think so.


The generated documentation from this doesn't correctly show namespaces.
> For example, with this source
>
>   1  Namespace N
>   2      Public Class C
>   3          Public Sub S()
>   4          End Sub
>   5      End Class
>   6  End Namespace
>
> the namespace N is documented as empty and class C has no namespace (with
> EXTRACT_ALL =3D YES). The tree of Entry that is being constructed in
> vbscanner.l contains C as a CLASS_SEC, as a child of N as a NAMESPACE_SEC=
.
> What am I doing wrong?


The class is not a child Entry of the namespace as far as I can see.

What I typically do:
- Copy the contents of the namespace to current->program
- in a second pass (so restarting the lexical scanner) parse the body of th=
e
namespace or class (one should do this recursively to support nested classe=
s
in nested namespaces...)

Look at parseCompounds() versus parseMain() in src/pyscanner.l for an
example.

Regards,
  Dimitri

[Doxygen-develop] Parser for VB.NET - namespaces

[James B. <jam...@mi...>]

I have started implementing support for VB.NET for Doxygen. The patch and
scanner for this are attached. Would there be interest in including this
in Doxygen?

The generated documentation from this doesn't correctly show namespaces.
For example, with this source

  1  Namespace N
  2      Public Class C
  3          Public Sub S()
  4          End Sub
  5      End Class
  6  End Namespace

the namespace N is documented as empty and class C has no namespace (with
EXTRACT_ALL = YES). The tree of Entry that is being constructed in
vbscanner.l contains C as a CLASS_SEC, as a child of N as a NAMESPACE_SEC.
What am I doing wrong?

James

Re: [Doxygen-develop] Qt Properties

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

On 3/30/06, Matthias Kretz <kr...@kd...> wrote:
>
> Hi again,
>
> I give up without a helping hand. Too many of the methods are not
> documented
> and I have to read to code only to figure out that they're not doing what
> I'm
> looking for. :-(
>
> I made doxygen write "Access function: " + getReadAccessor() +
> getWriteAccessor() in the property docs, but after about one day of
> reading
> doxygen source I had hoped to get further.
>
> If somebody can guide me on IRC I'm Vir on freenode or just reply to this
> list. I'm subscribed.


Please just report this in the bug tracker as a feature enhancement
(including an example) and I'll have a look. It probably takes me more time
to explain how to make the changes than it is to make the actual changes so
I think this is the best approach.

Regards,
  Dimitri

[Doxygen-develop] Documenting ActiveX libraries: support for helpcontext and hhc map file

[Reinhard N. <rn...@gm...>]

Hi,

I've documented each method of my ActiveX library and the resulting chm 
file is quite nice thanks to doxygen.

I'd now like to jump directly to a method documentation. Therefore I've 
added unique helpcontext numbers to all methods. But when I request a 
method's documentation, I always get the information that the chm file 
is missing a map section.

Are there any plans to support helpcontext and to provide a map file for 
hhc?

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...

Re: [Doxygen-develop] Qt Properties

[Matthias K. <kr...@kd...>]

Hi again,

I give up without a helping hand. Too many of the methods are not documente=
d=20
and I have to read to code only to figure out that they're not doing what I=
'm=20
looking for. :-(

I made doxygen write "Access function: " + getReadAccessor() +=20
getWriteAccessor() in the property docs, but after about one day of reading=
=20
doxygen source I had hoped to get further.

If somebody can guide me on IRC I'm Vir on freenode or just reply to this=20
list. I'm subscribed.

Good night,
	Matthias

On Wednesday 22 March 2006 22:49, Matthias Kretz wrote:
> Hi,
>
> while documenting properties for the upcoming KDE4 API I noticed that
> documenting Q_PROPERTY macros partially works. But there's a few things I=
'd
> like to fix if you can tell me where to look:
>
> 1. The HTML documentation doesn't specify what the ReadAccessor and
> WriteAccessor are. I like the way it is done for Qt (look at
> http://doc.trolltech.com/4.1/qaction.html#checked-prop ).
>
> So I'd like to add the necessary code to write out "Access function:\n - "
> + getReadAccessor() + "\n - " + getWriteAccessor()
> Where do I have to look (apparently the accessor functions are written in=
to
> the XML output, but not the HTML output)?
>
> 2. If the accessor functions are undocumented doxygen currently gives a
> warning. Ideally doxygen should see that the documentation is not needed
> anymore and link the functions from the index to the property documentati=
on
> and not give any warnings - to the contrary it should give a warning if t=
he
> property and the accessors are documented.
> Is this possible? Where?

=2D-=20
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
Mat...@gm..., kr...@kd...,
Mat...@ur...

[Doxygen-develop] Qt Properties

[Matthias K. <kr...@kd...>]

Hi,

while documenting properties for the upcoming KDE4 API I noticed that=20
documenting Q_PROPERTY macros partially works. But there's a few things I'd=
=20
like to fix if you can tell me where to look:

1. The HTML documentation doesn't specify what the ReadAccessor and=20
WriteAccessor are. I like the way it is done for Qt (look at=20
http://doc.trolltech.com/4.1/qaction.html#checked-prop ).

So I'd like to add the necessary code to write out "Access function:\n - " =
+=20
getReadAccessor() + "\n - " + getWriteAccessor()
Where do I have to look (apparently the accessor functions are written into=
=20
the XML output, but not the HTML output)?

2. If the accessor functions are undocumented doxygen currently gives a=20
warning. Ideally doxygen should see that the documentation is not needed=20
anymore and link the functions from the index to the property documentation=
=20
and not give any warnings - to the contrary it should give a warning if the=
=20
property and the accessors are documented.
Is this possible? Where?

=2D-=20
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
Mat...@gm..., kr...@kd...,
Mat...@ur...

[Doxygen-develop] Namespaces

[Daniel J. H. <da...@hi...>]

I have had some trouble with the way namespaces are handled in the XML 
output, so I dug into the Doxygen code a little bit.   In an instance 
where I have a C++ namespace declared as:

namespace ExampleNamespace {
    class A {
        ....
    }
}

I have found that the name of class A is rolled up into 
ExampleNamespace::A, so that there is no difference between the 
namespace name and the class name.   I looked through xmlgen.cpp and 
found that when outputting the class name A, the namespace (found 
through a getNamespaceDef call in the ClassDef object) is undefined.   
After this, I searched through doxygen.cpp and found that in static void 
addClassToContect(Entry *root) that the namespace of a class is stripped 
off into namespaceName and then never used.   Is this the desired 
behavior?  It seems to me that this name should be used to find the 
innermost namespace and assigned to m_nspace in order to fully define 
ClassDef.

Dan

RE: [Doxygen-develop] is it allowed to post an file-attachment over this mailing-list

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

Hi Eckard,

Your request sounds similar to something I did, although I'm not entirely
sure so tell me if I'm wrong :)

I wished to add message sequence charts as diagrams to the documentation,
but by adding a textual description of the MSC to the doxygen comments, in
the same way that DOT diagrams can be added.  

To make this easy to integrate into Doxygen, I enhanced doxygen with a \cmd
and \endcmd special command that would run a shell command.  The format is
something like this:

\cmd eps{mscgen -T eps -i $in -o $out} png{mscgen -T png -i $in -o $out}
ismap{mscgen -T ismap -i $in -o $out}
   ...
\endcmd

Doxygen looks at the line and depending on the type of output it requires
(eps for LaTeX, png and imagemaps for HTML etc..), then selects the command
line to use.  $in is replaced by a temporary file that contains any text
between the \cmd and \endcmd, and $out is the desired output name.
Generally I use ALIASES to make the command friendlier by substituting the
full \cmd and \endcmd lines to something easier to use. 

This change made it easy for me to call sub-programs for rendering any
textual data embedded into Doxygen comments. 

If you are interested, look at http://www.mcternan.co.uk/mscgen/index.html.
The doxygen bit is at the bottom, together with the source of course!

Regards,

Mike

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-develop-
> ad...@li...] On Behalf Of Eck...@t-...
> Sent: 13 March 2006 18:34
> Cc: Erik Zeek
> Subject: Re: [Doxygen-develop] is it allowed to post an file-attachment
> over this mailing-list
> 
> Hello Dr. Zeek.
> 
> Thank you for your answer.
> 
> My English is not very good, so may be I didn't wrote what I mean or I
> misunderstood your answer.
> The program I'm working on is not an origin part of doxygen. It should be
> a
> tool for doxygen like dot. So I wonder, if it is a good idea to report my
> problems as bugs of doxygen.
> 
> On the other hand I'm searching for a possibility to offer the developers
> (and, if they are interested in, the users) the possibility to test my
> program. I have no own home-page so I'm  thinking about posting the
> program
> on source-forge as own project. But this means for me to spend some time
> as
> project-administrator and time is a scarce good for me too.
> 
> I know that the developers of doxygen are volunteers which couldn't work
> on
> the project around the clock. But how should they respond without the
> chance
> to test my tool?
> 
> Eckard.
> 
> PS. Please forgive me if my mail sounds a little bit rough. It's always a
> little bit difficult for me to find the right words.
> 
> 
> 
> 
> ----- Original Message -----
> From: "Erik Zeek" <ze...@ma...>
> To: <dox...@li...>
> Cc: <Eck...@t-...>
> Sent: Sunday, March 12, 2006 7:39 PM
> Subject: Re: [Doxygen-develop] is it allowed to post an file-attachment
> over
> this mailing-list
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] is it allowed to post an file-attachment over this mailing-list

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

On Mon March 13 2006 13:33, Eck...@t-... wrote:
> Hello Dr. Zeek.
>
> Thank you for your answer.
>
> My English is not very good, so may be I didn't wrote what I mean or I
> misunderstood your answer.
> The program I'm working on is not an origin part of doxygen. It should
> be a tool for doxygen like dot. So I wonder, if it is a good idea to
> report my problems as bugs of doxygen.
>
> On the other hand I'm searching for a possibility to offer the
> developers (and, if they are interested in, the users) the possibility
> to test my program. I have no own home-page so I'm  thinking about
> posting the program on source-forge as own project. But this means for
> me to spend some time as project-administrator and time is a scarce good
> for me too.
>
> I know that the developers of doxygen are volunteers which couldn't work
> on the project around the clock. But how should they respond without the
> chance to test my tool?
>
> Eckard.
>
> PS. Please forgive me if my mail sounds a little bit rough. It=E2=80=99s =
always
> a little bit difficult for me to find the right words.

Eckard,

Your English is fine.  I just didn't read it well enough.

Your best best is SF.net or some similar site.  If you can get more that=20
just Doxygen people interested, you're tool stands a much better chance of=
=20
being used.

As a backup plan you could use a free hosting service to host an archive of=
=20
the source and publicize it here.  A potential site is:=20
http://www.webfilehost.com/  They claim to host files for free (add=20
supported).

Erik
=2D-=20
*******************************************
Dr. Erik Zeek
Postdoctoral Research Associate
Department of Physics and Astronomy
The University of Georgia
Athens, GA 30602-2451

Tel: 706-542-7293
Email: mailto:ze...@ma...
Html:  http://www.physast.uga.edu/~zeekec
*******************************************
Against stupidity the very gods
Themselves contend in vain.
  - Johann Christoph Friedrich von Schiller (1801)
*******************************************

Re: [Doxygen-develop] is it allowed to post an file-attachment over this mailing-list

[<Eck...@t-...>]

Hello Dr. Zeek.

Thank you for your answer.

My English is not very good, so may be I didn't wrote what I mean or I
misunderstood your answer.
The program I'm working on is not an origin part of doxygen. It should be a
tool for doxygen like dot. So I wonder, if it is a good idea to report my
problems as bugs of doxygen.

On the other hand I'm searching for a possibility to offer the developers
(and, if they are interested in, the users) the possibility to test my
program. I have no own home-page so I'm  thinking about posting the program
on source-forge as own project. But this means for me to spend some time as
project-administrator and time is a scarce good for me too.

I know that the developers of doxygen are volunteers which couldn't work on
the project around the clock. But how should they respond without the chance
to test my tool?

Eckard.

PS. Please forgive me if my mail sounds a little bit rough. It’s always a
little bit difficult for me to find the right words.




----- Original Message ----- 
From: "Erik Zeek" <ze...@ma...>
To: <dox...@li...>
Cc: <Eck...@t-...>
Sent: Sunday, March 12, 2006 7:39 PM
Subject: Re: [Doxygen-develop] is it allowed to post an file-attachment over
this mailing-list

Re: [Doxygen-develop] is it allowed to post an file-attachment over this mailing-list

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

On Sun March 12 2006 04:24, Eck...@t-... wrote:
> Dear Admin of the mailing-list for doxygen-developers.
>
>
>
> As I wrote before I'm working on a program to generate diagrams which
> describes the algorithm of c/c++ functions and which can be included in
> a doxygen-output.
>
> It should be an add-on for doxygen so I should discuss it with other
> developers. But therefore I have to offer them some files for example
> the program, configuration-files and some documentation. Is it possible
> and, if so, is it allowed to post this as an file-attachment over this
> mailing-list. I have no own home-page and so I couldn't offer a=20
> download-possibility.
>
>
>
> Regards,
>
>               Eckard Klotz.

I believe the standard way of doing this is to file a bug report=20
(http://bugzilla.gnome.org/enter_bug.cgi?product=3Ddoxygen) severity=20
"enhancement".  Then post a link to the bug asking for discussion of the=20
code.

Erik

P.S.  Please remember that the developers of Doxygen (I'm not one of=20
those.) are volunteers, and it may take them awhile to respond.
=2D-=20
*******************************************
Dr. Erik Zeek
Postdoctoral Research Associate
Department of Physics and Astronomy
The University of Georgia
Athens, GA 30602-2451

Tel: 706-542-7293
Email: mailto:ze...@ma...
Html:  http://www.physast.uga.edu/~zeekec
*******************************************
Against stupidity the very gods
Themselves contend in vain.
  - Johann Christoph Friedrich von Schiller (1801)
*******************************************

[Doxygen-develop] is it allowed to post an file-attachment over this mailing-list

[<Eck...@t-...>]

Dear Admin of the mailing-list for doxygen-developers.

=20

As I wrote before I'm working on a program to generate diagrams which =
describes the algorithm of c/c++ functions and which can be included in =
a doxygen-output.

It should be an add-on for doxygen so I should discuss it with other =
developers. But therefore I have to offer them some files for example =
the program, configuration-files and some documentation. Is it possible =
and, if so, is it allowed to post this as an file-attachment over this =
mailing-list. I have no own home-page and so I couldn't offer a  =
download-possibility.

=20

Regards,

              Eckard Klotz.

Re: [Doxygen-develop] [PATCH] graphviz bugfix broke doxygen

[Kevin M. <ke...@pl...>]

Hello,

It's a good thing that you are submitting patches to the developer list,
and we appreciate you submitting your patches.  However, we prefer all
bugs to be filed within the bugzilla, even if you have the patches to
fix the bugs.  Doing so makes it easier for us to add fixed bugs to the
ChangeLogs, and make better use of bugzilla reports. :)

As a courtesy, I imported the patch into the bugzilla for you:

http://bugzilla.gnome.org/show_bug.cgi?id=333270

Thank you,

- KJM

John Ellson wrote:
> 
> There is a change in the Postscript output of dot from 
> graphviz-2.9.20060302.0540 (and later) to use %%BoundingBox: (atend) 
> so as to properly support multiple graphs in a single PostScript file
>  according to page 39 of: 
> http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf
> 
> Unfortunately this breaks doxygen which expects the first 
> %%BoundingBox: record to contain the coordinates.
> 
> To fix this in a backward compatible way I suggest that doxygen 
> should use the %%PageBoundingBox instead.
> 
> John
> 
> 
> 
> Index: src/dot.cpp 
> =================================================================== 
> RCS file: /cvsroot/doxygen/src/dot.cpp,v retrieving revision 1.107 
> diff -r1.107 dot.cpp 277c277 <     if (strncmp(buf,"%%BoundingBox: 
> ",15)==0) ---
>> if (strncmp(buf,"%%PageBoundingBox: ",19)==0)
> 280c280 <       if (sscanf(buf,"%%%%BoundingBox: %d %d %d 
> %d",&x,&y,width,height)!=4) ---
>> if (sscanf(buf,"%%%%PageBoundingBox: %d %d %d
> %d",&x,&y,width,height)!=4)
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------- This SF.Net 
> email is sponsored by xPML, a groundbreaking scripting language that 
> extends applications into web and mobile media. Attend the live 
> webcast and join the prime developer group breaking into this new 
> coding territory! 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>  _______________________________________________ Doxygen-develop 
> mailing list Dox...@li... 
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 


-- 
This message has been digitally signed with a GlobalSign-issued certificate.
For more information, please visit GlobalSign's web site at:
http://www.globalsign.net/

[Doxygen-develop] [PATCH] graphviz bugfix broke doxygen

[John E. <el...@re...>]

There is a change in the Postscript output of dot from 
graphviz-2.9.20060302.0540 (and later) to use
    %%BoundingBox: (atend) 
so as to properly support multiple graphs in a single PostScript file 
according to page 39 of:
    http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

Unfortunately this breaks doxygen which expects the first %%BoundingBox: 
record to contain the coordinates.

To fix this in a backward compatible way I suggest that doxygen should 
use the %%PageBoundingBox instead.

John



Index: src/dot.cpp
===================================================================
RCS file: /cvsroot/doxygen/src/dot.cpp,v
retrieving revision 1.107
diff -r1.107 dot.cpp
277c277
<     if (strncmp(buf,"%%BoundingBox: ",15)==0)
---
 >     if (strncmp(buf,"%%PageBoundingBox: ",19)==0)
280c280
<       if (sscanf(buf,"%%%%BoundingBox: %d %d %d 
%d",&x,&y,width,height)!=4)
---
 >       if (sscanf(buf,"%%%%PageBoundingBox: %d %d %d 
%d",&x,&y,width,height)!=4)

Re: [Doxygen-develop] Shorter syntax for grouping class members

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

Hi Daniel,

One of the issues with the @members command is the definition of where the
group ends. I'm sure there are different (and equally correct)
opinions/expectations about that, e.g.

class Test
{
  public:
    /** @members A group
    */
    void func1();
    void func2();
  private:
    int var;
};

will the group include var or not? i.e. does a group locigally end at
"private:" and if so then what if there was no "private:"?

Nevertheless, if you have a patch that implements the @members
command, I'll merge it.

Regards,
  Dimitri

On 2/8/06, Daniel Ferber <dan...@te...> wrote:
>
> Hi,
>
> I would like to propose a shorter, easier and more readable syntax for
> grouping members in a class. I searched the mail archive but didnt find
> messages about this.
>
> With doxygen, if I want to create a group of class members, nowadays I
> have to
> write:
> /**
> * @name ...
> * About the group
> */
> //@{
> ...
> //@}
>
> My suggestion is to create a new command (eg @members) that automatically
> starts a new group which goes until the next @members or until the class
> is
> closed.
>
> /**
> * @members About the group
> */
> ....
>
> /**
> * @members About the group
> */
> ....
>
> IMHO, my suggestion is simplier and more readable.
> In large classes, with many groups, the lines with  //@} and  //@{
> comments
> make them difficult to read. IDEs do not understand these comments and do
> not
> provide folding or hiding. The grouping results in an overhead of 4
> additional lines. The //@} and  //@{ are difficult to see and easy to
> forget.
>
> On well organized projects, class attributes and methods are frequently
> grouped. I like to group them at least like: attributes, references,
> constructor/destructor and several groups of methods.
> As this kind of grouping is very frequent, I believe that it could have a
> special syntax for it.
>
> I am only concerned with classes, but I think a more gerenal model could
> be
> implemented to make grouping of other entities easier and more readable.
>
> Thanks,
> DAniel FF
>
>
>

[Doxygen-develop] "protected" structs in Objective-C

[Ryan B. <rb...@gm...>]

There seems to be a bit of a nasty bug where a struct as an instance  
member of an Objective-C interface will make doxygen crap.

If you're on OS X, make sure EXTRACT_ALL is on, and set INPUT to this  
single header file (the AppKit headers make a good example for  
Objective-C header files):

	/System/Library/Frameworks/AppKit.framework/Headers/NSBitmapImageRep.h

Now run dox. Review the output -- there's nothing documented.

The problem is this block in that header file:

@interface NSBitmapImageRep : NSImageRep {
     /*All instance variables are private*/
     struct __bitmapRepFlags {
        unsigned int bitsPerPixel:8;
         unsigned int isPlanar:1;
         unsigned int explicitPlanes:1;
         unsigned int isUnpacked:1;
         unsigned int dataLoaded:1;
         unsigned int numColors:4;       /* Cache */
          unsigned int memory:2;
         unsigned int compressionFactor:14;
         unsigned int imageNumber:8;
         unsigned int bitmapFormat:3;
         unsigned int reserved:1;
         unsigned int compression:20;
     } _moreRepFlags;
     unsigned int _bytesPerRow;
     unsigned char *_data;
     NSData *_tiffData;
     id _properties;
}

The struct called __bitmapRepFlags is the problem. Commenting that  
out like so:

@interface NSBitmapImageRep : NSImageRep {
     /*All instance variables are private*/
    /*
    struct __bitmapRepFlags {
        unsigned int bitsPerPixel:8;
         unsigned int isPlanar:1;
         unsigned int explicitPlanes:1;
         unsigned int isUnpacked:1;
         unsigned int dataLoaded:1;
         unsigned int numColors:4;       /* Cache */
          unsigned int memory:2;
         unsigned int compressionFactor:14;
         unsigned int imageNumber:8;
         unsigned int bitmapFormat:3;
         unsigned int reserved:1;
         unsigned int compression:20;
     } _moreRepFlags;
     */
     unsigned int _bytesPerRow;
     unsigned char *_data;
     NSData *_tiffData;
     id _properties;
}

...and then running dox again results in complete documentation for  
that header file. It seems whenever dox finds a struct as a protected  
member, something happens such that it doesn't add any of the symbols  
to the group to document.

Has anyone else seen this issue? I would be happy to write a patch  
for this, but I'd appreciate some pointers as to where to search for  
the problem. I've been able to determine that once parseFiles() hits  
the struct, neither it or any of the following symbols get placed  
onto the "root" variable that eventually gets munged by buildGroupList 
(). But finding the problem within parseFiles() and the associated  
lex, I don't know where to start.

Thanks for your help.

Ryan

Re: [Doxygen-develop] nassi-shneidermann generator for doxygen

[Kevin M. <ke...@pl...>]

Eck...@t-... wrote:
> I’m still in the process of design and implementation, and the 
> documentation is also incomplete (perhaps a little bit confusing). 
> But I thought it is a good idea to give you the chance to take a look
>  to it. Thus I sent you some zip-files with a demo-version last 
> December (16.12.2005 “add-on for DoxyGen”). I hope you received them.

Do you mind of sending me the archive as well?  I am not sure if Dimitri
is able to open zip archives, but my Fedora Core system has the unzip
utility that can extract them.

- KJM

-- 
This message has been digitally signed with a GlobalSign-issued certificate.
For more information, please visit GlobalSign's web site at:
http://www.globalsign.net/

[Doxygen-develop] nassi-shneidermann generator for doxygen

[<Eck...@t-...>]

Dear Mr. Van Heesch.=20
=20
My name is Eckard Klotz. I sent you an e-mail last year (16.12.2005 =
"add-on for DoxyGen") to introduce you my "add-on" project for doxygen =
named "Moritz". I hope you received it and remember.=20
=20
Moritz is a tool, that should generate nassi-shneidermann diagrams of =
c/c++ functions. The tool needs the xml-output of doxygen and generates =
html-files as result, which may be included in the documentation via =
htmlinclude. =20
=20
I'm still in the process of design and implementation, and the =
documentation is also incomplete (perhaps a little bit confusing). But I =
thought it is a good idea to give you the chance to take a look to it. =
Thus I sent you some zip-files with a demo-version last December =
(16.12.2005 "add-on for DoxyGen"). I hope you received them.=20
=20
OK. You will get a lot of e-mails and you will not have the time to =
answer them all. But my project is still in progress so I wonder how it =
is possible to introduce you a newer version. At the moment I have no =
own homepage to offer the newest version as a freeware-download (But I =
want to do this in the future when Moritz becomes ready an stable ). But =
I want to give you the chance to influence the design, so that Moritz =
becomes compatible tool for doxygen and its users.=20
=20
I think doxygen is a great tool and it helps me in my job day by day, so =
I hope you are not angry about my project. I don't think that I can make =
your job better than you. This should only be the try to help you. =20
=20
Best regards,=20
                    Eckard Klotz.=20



PS: This is an other try to send this mail to the list =
"doxygen-devellop". The first was before I subscribed the list. So if =
this text is allready postesd sorry!

[Doxygen-develop] Fw: nassi-shneidermann generator for doxygen

[<Eck...@t-...>]

Dear Mr. Van Heesch.=20
=20
My name is Eckard Klotz. I sent you an e-mail last year (16.12.2005 =
"add-on for DoxyGen") to introduce you my "add-on" project for doxygen =
named "Moritz". I hope you received it and remember.=20
=20
Moritz is a tool, that should generate nassi-shneidermann diagrams of =
c/c++ functions. The tool needs the xml-output of doxygen and generates =
html-files as result, which may be included in the documentation via =
htmlinclude. =20
=20
I'm still in the process of design and implementation, and the =
documentation is also incomplete (perhaps a little bit confusing). But I =
thought it is a good idea to give you the chance to take a look to it. =
Thus I sent you some zip-files with a demo-version last December =
(16.12.2005 "add-on for DoxyGen"). I hope you received them.=20
=20
OK. You will get a lot of e-mails and you will not have the time to =
answer them all. But my project is still in progress so I wonder how it =
is possible to introduce you a newer version. At the moment I have no =
own homepage to offer the newest version as a freeware-download (But I =
want to do this in the future when Moritz becomes ready an stable ). But =
I want to give you the chance to influence the design, so that Moritz =
becomes compatible tool for doxygen and its users.=20
=20
I think doxygen is a great tool and it helps me in my job day by day, so =
I hope you are not angry about my project. I don't think that I can make =
your job better than you. This should only be the try to help you. =20
=20
Best regards,=20
Eckard Klotz.=20



PS: This is an other try to send this mail to the list =
"doxygen-devellop". The first was before I subscribed the list. So if =
this text is allready postesd sorry!

[Doxygen-develop] Shorter syntax for grouping class members

[Daniel F. <dan...@te...>]

Hi,

I would like to propose a shorter, easier and more readable syntax for 
grouping members in a class. I searched the mail archive but didnt find 
messages about this.

With doxygen, if I want to create a group of class members, nowadays I have to 
write:
/**
 * @name ...
 * About the group
 */
 //@{
 ...
 //@}

My suggestion is to create a new command (eg @members) that automatically 
starts a new group which goes until the next @members or until the class is 
closed. 

/** 
 * @members About the group
 */
....

/**
 * @members About the group
 */
....

IMHO, my suggestion is simplier and more readable.
In large classes, with many groups, the lines with  //@} and  //@{ comments 
make them difficult to read. IDEs do not understand these comments and do not 
provide folding or hiding. The grouping results in an overhead of 4 
additional lines. The //@} and  //@{ are difficult to see and easy to forget.

On well organized projects, class attributes and methods are frequently 
grouped. I like to group them at least like: attributes, references, 
constructor/destructor and several groups of methods.
As this kind of grouping is very frequent, I believe that it could have a 
special syntax for it.

I am only concerned with classes, but I think a more gerenal model could be 
implemented to make grouping of other entities easier and more readable.

Thanks,
DAniel FF