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

Re: [Doxygen-develop] File version numbers

[Maik H. <ma...@hi...>]

Hello,

I have not a cvs repository at home or work but subversion.

A small script will help to get version numbers.

#!/bin/bash
svn stat -v $1 | sed -n 's/^[ A-Z?\*|!]\{1,15\}/r/;s/ \{1,15\}/\/r/;s/ .*//=
p'

This script return the file version in the form r123/r121. The first number=
 is=20
the working-revision of the file. The second show the revision in which the=
=20
file last changed.

=46or example store the script as get_svn_version.sh and add it to paramete=
r=20
=46ILE_VERSION_INFO:

=46ILE_VERSION_INFO =3D get_svn_version.sh=20

The script is not perfect but shows the way.

Cu,
Maik

On Monday 20 December 2004 19:24, Dimitri van Heesch wrote:
> On Fri, Dec 17, 2004 at 05:16:29PM +0100, Maik Hinrichs wrote:
> > Hello,
> >
> > attached patch makes it possible to determine versions of files from the
> > version control system  and integrate an according version string in the
> > documentation.
>
> Thanks for the patch, but I was wondering how one would use this with
> open source CM tools such as CVS? Just like to know because I'll probably
> get this question when I include this patch.
>
> Regards,
>   Dimitri

Re: [Doxygen-develop] File version numbers

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

On Fri, Dec 17, 2004 at 05:16:29PM +0100, Maik Hinrichs wrote:
> Hello,
> 
> attached patch makes it possible to determine versions of files from the 
> version control system  and integrate an according version string in the 
> documentation.

Thanks for the patch, but I was wondering how one would use this with 
open source CM tools such as CVS? Just like to know because I'll probably 
get this question when I include this patch.

Regards,
  Dimitri

[Doxygen-develop] tree.html: meta items: there is one quot to much !

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

Hi 

I am using doxygen version 1.3.9.1-20041213

I think in the "tree.html" files that are 
generate by doxygen there is one quot too much !


> find . -name "*.html" -exec  grep -H meta {} \; | grep  iso  | grep charset=\"
./const_char_p.c.dir_docu/html/tree.html:      <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./const_char_p_const.c.dir_docu/html/tree.html:<meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./char_p_const.c.dir_docu/html/tree.html:      <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./int_p_const.c.dir_docu/html/tree.html:       <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./int_p.c.dir_docu/html/tree.html:             <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./char_p.c.dir_docu/html/tree.html:            <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./const_int.c.dir_docu/html/tree.html:         <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
./const_const.c.dir_docu/html/tree.html:       <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />

wrong:
 <meta http-equiv="Content-Type" content="text/xhtml;charset="iso-8859-1" />
right:
 <meta http-equiv="Content-Type" content="text/xhtml;charset=iso-8859-1" />

Found in source code (in dir "src"):
> grep -n meta *.c* | grep http
 ok:  ftvhelp.cpp:597:    t << "<meta http-equiv=\"Content-Type\" content=\"text/html;charset="
 err: ftvhelp.cpp:633:    t << "    <meta http-equiv=\"Content-Type\" content=\"text/xhtml;charset=\""
 ok:  ftvhelp.cpp:635:    t << "    <meta http-equiv=\"Content-Style-Type\" content=\"text/css\" />\n";
 ok:  ftvhelp.cpp:636:    t << "    <meta http-equiv=\"Content-Language\" content=\"en\" />\n";
 ok:  htmlgen.cpp:405:    "<meta http-equiv=\"Content-Type\" content=\"text/html;charset="

Can you please correct that one in ftvhelp.cpp line 633 ?

Thanks for listening
Enno

Re: RE : RE : [Doxygen-develop] new feature discussion

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

On Wed, 15 Dec 2004 12:32:55 +0100, Antoine Tandin
<at...@ko...> wrote:
> Of course showing group dependencies is a great feature.
> I would like to have this feature (I'm ready to code it:))
> 
> But I think doing only one big graph showing all relations/dependencies
> of groups will very nice but probably unreadable, so useless.
> 

Maybe I wasn't very clear, but I meant to have a class collaboration diagram
showing ONLY those classes that are in the SAME group (a box per class and
edges for the relations with other classes in the same group). Unless 
someone puts all classes in one group (which doesn't make too much sense),
the diagram will only a small number of boxes and edges. Same idea applies 
for files.

> This is why I started with the group collaboration graph.
> The aim of this graph is to show "dependencies" created by the way the
> code is documented.
> This graph show only explicit relations between groups : means
> "ingroup"... commands only.

This is indeed a valid graph of its own, but I do not think relation between
classes, etc that are in multiple groups need to be shown (they are now).

> For example, from doxygen, we can create some of those groups :
> - Group Dot : groups about dot features stuff. Contains dot.h dot.cpp
> ... classes in those files...
> - Group HTML Output : everything about html feature. Contains htmlgen.h,
> htmlhelp.h, htmlattrib.h ...,default css file..., htmlgen class ...
> - Group LATEX : same as html
> - Group MAN : same as html
> - Group Ouputgen : everything about exporting doxygen doc. Contain files
> ... outputgen class... and of course contains groups HTML, LATEX, MAN
> ...
> 
> In "htmlgen class", the function "startDotGraph" is specialized for
> exporting a dot graph for html format.
> So it is relevant to explicitly put the function in the "Dot" group and
> the "htlm ouput" group.
> Same for "latexgen" BUT not for "mangen" because there is no dot output
> for man pages (even if the function exist, it does nothing).
> 
> The group collaboration graph will show that Dot feature is in relation
> with HTML and LATEX features (and by deduction outputgen) by the
> functions "startDotGraph".
> The graph will not show link with Dot and MAN, this is good because
> there is no relevant link.
> 
> Now let's create a graph using real code dependencies.
> You will see more relations between Dot and outputgen groups because of
> implementation (like outputlist::startDotGraph) and you will also see a
> link between Dot and MAN because the empty function
> mangen::startDotGraph is called.
> In an other hand, in this kind of graph, you can't see shared data file
> between group, because the "code" is not aware of that.
> 
> So I think those 2 kind of graph have 2 different purpose :
> - the first shows the "design" dependencies : that is why I called id
> "collaboration graph"
> - the second shows the "implementation" dependencies : I would use the
> term "dependency" for this kind of graph.

I think I understand what you mean. Problem is that everyone seems to
have a different idea what a collaboration graph is (in UML it is again
something else). 

I agree it would be useful to have a way to just mention a couple of 
classes (or files, dirs, groups,...) and that doxygen produces a image 
with just those classes (...) and their relations. Maybe the relations 
can also be user defined, but then it is pretty close to what is already 
possible with \dot .. \enddot.
 
> Once again the "implementation dependency" can be very heavy.
> So I think it is better to split it into more lighten specialized graphs
> like : include and file dependency (your point 3), class inheritance and
> relation dependencies(your point 2), and the function call dependencies
> (using refby stuff).
> 
> Even spitted, those graph will most of the time quite "heavy".
> If you have some framework group (like QT stuff for instance: qt list,
> qtstream..., or file sytem, memory, thread...) those groups will always
> appear in the graphs, because those groups are used everywhere in the
> code.
> It mean every group dependencies graph of you project will have most of
> the time a "minimum" number elements.

Not if you exclude any classes that are not in the group.

Regards,
  Dimitri

[Doxygen-develop] File version numbers

[Maik H. <ma...@hi...>]

Hello,

attached patch makes it possible to determine versions of files from the 
version control system  and integrate an according version string in the 
documentation.

Comments are welcome!

Cu,
Maik

Re: [Doxygen-develop] Re: Segfault in test t6 regessions suit

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

Hi
updated to new version (1.3.9.1-20041213)
using version 2.2.0 of valgrind
no segmentation fault anymore!!!

testing t1.cpp... OK
testing t2.cpp... OK
testing t3.cpp... FAILED due to differences in output
testing t4.cpp... OK
testing t5.cpp... OK
testing t7.cpp... OK
testing t6.c... OK
testing t8.m... FAILED due to differences in output

Only on test t8.m there is an uninitialised value
> valgrind --trace-children=3Dyes  --num-callers=3D15 --tool=3Dmemcheck sh =
check.sh
=2E.................
testing t8.m...
=2E..
=3D=3D8690=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 fr=
om 1)
=3D=3D8690=3D=3D malloc/free: in use at exit: 24029 bytes in 1059 blocks.
=3D=3D8690=3D=3D malloc/free: 8975 allocs, 7916 frees, 256321 bytes allocat=
ed.
=3D=3D8690=3D=3D For a detailed leak analysis,  rerun with: --leak-check=3D=
yes
=3D=3D8690=3D=3D For counts of detected errors, rerun with: -v
=3D=3D8691=3D=3D Conditional jump or move depends on uninitialised value(s)
=3D=3D8691=3D=3D    at 0x818948C: ClassDef::compoundTypeString() const (cla=
ssdef.cpp:2490)
=3D=3D8691=3D=3D    by 0x817D598: ClassDef::ClassDef(char const*, int, char=
 const*, ClassDef::CompoundType, char const*, char const*, bool) (classdef.=
cpp:50)
=3D=3D8691=3D=3D    by 0x804BFE9: addClassToContext(Entry*) (doxygen.cpp:77=
3)
=3D=3D8691=3D=3D    by 0x804C2AC: buildClassList(Entry*) (doxygen.cpp:854)
=3D=3D8691=3D=3D    by 0x804C2EC: buildClassList(Entry*) (doxygen.cpp:860)
=3D=3D8691=3D=3D    by 0x8068EF4: parseInput() (doxygen.cpp:8542)
=3D=3D8691=3D=3D    by 0x8049C26: main (main.cpp:102)
=3D=3D8691=3D=3D
=3D=3D8691=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 fr=
om 1)
=3D=3D8691=3D=3D malloc/free: in use at exit: 874832 bytes in 61 blocks.
=3D=3D8691=3D=3D malloc/free: 19390 allocs, 19329 frees, 1683171 bytes allo=
cated.
=3D=3D8691=3D=3D For a detailed leak analysis,  rerun with: --leak-check=3D=
yes
=3D=3D8691=3D=3D For counts of detected errors, rerun with: -v
=3D=3D8698=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D8698=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D8698=3D=3D Using valgrind-2.2.0, a program supervision framework for =
x86-linux.
=3D=3D8698=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D8698=3D=3D For more details, rerun with: -v
=2E..
=46AILED due to differences in output
=2E...............



Thanks for listening

Am Montag, 13. Dezember 2004 20:11 schrieb Dimitri van Heesch:
> On Sun, 12 Dec 2004 12:30:26 +0100, Enno Bartels
>
> <enn...@t-...> wrote:
> > Hi
> >
> > Had problems with doxygen in the regressions suit
> > at test t6
> >
> > Output:
> > > sh check.sh
> >
> > testing t1.cpp... OK
> > testing t2.cpp... OK
> > testing t3.cpp... FAILED due to differences in output
> > testing t4.cpp... OK
> > testing t5.cpp... OK
> > testing t7.cpp... OK
> > testing t6.c...check.sh: line 41: 12998 Done                    ( cat
> > update.dox; echo "XML_OUTPUT=3Dtmp"; echo "PROJECT_NAME=3D$i"; echo
> > "INPUT=3D$i"; echo "WARN_LOGFILE=3D$i.log" ) 12999 Speicherzugriffsfehl=
er  |
> > doxygen -
> > mv: Aufruf von stat f=FCr =BBtmp/*=AB nicht m=F6glich: Datei oder Verze=
ichnis
> > nicht gefunden cat: tmp/*.org: Datei oder Verzeichnis nicht gefunden
> > rm: Entfernen von =BBtmp/*.org=AB nicht m=F6glich: Datei oder Verzeichn=
is nicht
> > gefunden FAILED due to differences in output
> > testing t8.m... FAILED due to differences in output
> >
> > > doxygen --version
> >
> > 1.3.9.1-20041206
>
> Hmm, could you retry with the new version (1.3.9.1-20041213). The
> regression tests
> work fine with valgrind for me (I'm using version 2.2.0 of valgrind).
>
> Regards,
>   Dimitri
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

RE : RE : [Doxygen-develop] new feature discussion

[Antoine T. <at...@ko...>]

Of course showing group dependencies is a great feature.
I would like to have this feature (I'm ready to code it:))

But I think doing only one big graph showing all relations/dependencies
of groups will very nice but probably unreadable, so useless.

This is why I started with the group collaboration graph.
The aim of this graph is to show "dependencies" created by the way the
code is documented.
This graph show only explicit relations between groups : means
"ingroup"... commands only.

For example, from doxygen, we can create some of those groups :
- Group Dot : groups about dot features stuff. Contains dot.h dot.cpp
... classes in those files...
- Group HTML Output : everything about html feature. Contains htmlgen.h,
htmlhelp.h, htmlattrib.h ...,default css file..., htmlgen class ...
- Group LATEX : same as html
- Group MAN : same as html
- Group Ouputgen : everything about exporting doxygen doc. Contain files
... outputgen class... and of course contains groups HTML, LATEX, MAN
...

In "htmlgen class", the function "startDotGraph" is specialized for
exporting a dot graph for html format.=20
So it is relevant to explicitly put the function in the "Dot" group and
the "htlm ouput" group.
Same for "latexgen" BUT not for "mangen" because there is no dot output
for man pages (even if the function exist, it does nothing).

The group collaboration graph will show that Dot feature is in relation
with HTML and LATEX features (and by deduction outputgen) by the
functions "startDotGraph".
The graph will not show link with Dot and MAN, this is good because
there is no relevant link.


Now let's create a graph using real code dependencies.
You will see more relations between Dot and outputgen groups because of
implementation (like outputlist::startDotGraph) and you will also see a
link between Dot and MAN because the empty function
mangen::startDotGraph is called.
In an other hand, in this kind of graph, you can't see shared data file
between group, because the "code" is not aware of that.

So I think those 2 kind of graph have 2 different purpose :
- the first shows the "design" dependencies : that is why I called id
"collaboration graph"
- the second shows the "implementation" dependencies : I would use the
term "dependency" for this kind of graph.

Once again the "implementation dependency" can be very heavy.
So I think it is better to split it into more lighten specialized graphs
like : include and file dependency (your point 3), class inheritance and
relation dependencies(your point 2), and the function call dependencies
(using refby stuff).

Even spitted, those graph will most of the time quite "heavy".
If you have some framework group (like QT stuff for instance: qt list,
qtstream..., or file sytem, memory, thread...) those groups will always
appear in the graphs, because those groups are used everywhere in the
code.
It mean every group dependencies graph of you project will have most of
the time a "minimum" number elements.

I think this is not a problem, because the aim of those graph is not to
be "easy to read" but to point out all real direct or indirect
dependencies.


For all of those class of graph, it could be very useful to have one big
graph which plays with all groups.
Like done for class hierarchy and collaboration graph.
Means one big :
- groups "collaboration" graph
- groups "call dependencies" graph
- groups "include and file dependencies" graph
- groups "class dependencies" graph

Regards

-----Message d'origine-----
De=A0: Dimitri van Heesch [mailto:do...@gm...]=20
Envoy=E9=A0: lundi 13 d=E9cembre 2004 20:35
=C0=A0: Antoine Tandin
Cc=A0: dox...@li...
Objet=A0: Re: RE : [Doxygen-develop] new feature discussion

On Fri, 10 Dec 2004 10:41:50 +0100, Antoine Tandin
<at...@ko...> wrote:
> diff file attached for an implementation of those 4 features. Critics
> are welcome :)

I would like to discuss the usefulness of the group graphs (now this
is added and
people can try).

I think it is not too useful to have edges for elements that are in
multiple groups.
Any opions about this are welcome.

When I think about groups I can think of three types of graphs that I
think could be
useful:
1) A graph showing the containment relations between groups. This is
basically
     a simplified version from what is available now.
2) A graph showing all classes in a group and their relations (both
inheritance and
     using relations).
3) A graph showing all files in a group and their #include dependency
relations.

Depending on the group any of the 3 types of graphs could provide
useful information.

Let me know what you think about this idea.

Regards,
  Dimitri


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Build libraries on Solaris (sparc)

[Maik H. <ma...@hi...>]

Hello,

yes, solaris-g++ works fine. But solaris-cc is autodetected by configure.

Snippid of configure:
=20
=A0 =A0 =A0 f_platform=3Dsco-g++
=A0 =A0 =A0 ;;
=A0 =A0 SunOS:4*)
=A0 =A0 =A0 f_platform=3Dsunos-g++
=A0 =A0 =A0 ;;
=A0 =A0 SunOS:5*)
=A0 =A0 =A0 f_platform=3Dsolaris-cc
=A0 =A0 =A0 ;;
=A0 =A0 ULTRIX:*)
=A0 =A0 =A0 f_platform=3Dultrix-g++
=A0 =A0 =A0 ;;
=A0 =A0 UNIX_SV:4.2*)
=A0 =A0 =A0 f_platform=3Dunixware-g++
=A0 =A0 =A0 ;;

My target is a Solaris 9 (SunOS 5.9) on a Netra t 1405 (4x UltraSparc II)=20
hardware.

"uname -a" returns "SunOS developix 5.9 Generic_112233-11 sun4u sparc=20
SUNW,Ultra-80 Solaris" and so  "SunOS:5*" will match in configure script.

Regards, Maik


On Saturday 11 December 2004 10:41, Dimitri van Heesch wrote:
> On Thu, Dec 09, 2004 at 09:44:16PM +0100, Maik Hinrichs wrote:
> > Hello,
> >
> > I had to make a small change in file tmake.conf of target solaris-cc to
> > translate the libraries.
> >
> > I changed value of TMAKE_AR from "CC -xar -o" to "ar cqs".
> >
> > System: SunOS 5.9 (sparc)
> > Compiler: CC (gcc 3.3.2)
>
> If you use gcc, you should use solaris-g++ as a target, this should have
> the correct TMAKE_AR setting.
>
> Regards,
>   Dimitri

[Doxygen-develop] [PATCH]Prettier HTML output in IE

[Mikhail G. <bb...@ma...>]

This small patch prevents table "mdTable" from 
stretching outside window borders in IE(tested 
with IE6).

Re: RE : [Doxygen-develop] new feature discussion

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

On Fri, 10 Dec 2004 10:41:50 +0100, Antoine Tandin
<at...@ko...> wrote:
> diff file attached for an implementation of those 4 features. Critics
> are welcome :)

I would like to discuss the usefulness of the group graphs (now this
is added and
people can try).

I think it is not too useful to have edges for elements that are in
multiple groups.
Any opions about this are welcome.

When I think about groups I can think of three types of graphs that I
think could be
useful:
1) A graph showing the containment relations between groups. This is basically
     a simplified version from what is available now.
2) A graph showing all classes in a group and their relations (both
inheritance and
     using relations).
3) A graph showing all files in a group and their #include dependency relations.

Depending on the group any of the 3 types of graphs could provide
useful information.

Let me know what you think about this idea.

Regards,
  Dimitri

[Doxygen-develop] Re: Segfault in test t6 regessions suit

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

On Sun, 12 Dec 2004 12:30:26 +0100, Enno Bartels
<enn...@t-...> wrote:
> Hi
>=20
> Had problems with doxygen in the regressions suit
> at test t6
>=20
> Output:
> > sh check.sh
> testing t1.cpp... OK
> testing t2.cpp... OK
> testing t3.cpp... FAILED due to differences in output
> testing t4.cpp... OK
> testing t5.cpp... OK
> testing t7.cpp... OK
> testing t6.c...check.sh: line 41: 12998 Done                    ( cat upd=
ate.dox; echo "XML_OUTPUT=3Dtmp"; echo "PROJECT_NAME=3D$i"; echo "INPUT=3D$=
i"; echo "WARN_LOGFILE=3D$i.log" )
>      12999 Speicherzugriffsfehler  | doxygen -
> mv: Aufruf von stat f=FCr =BBtmp/*=AB nicht m=F6glich: Datei oder Verzeic=
hnis nicht gefunden
> cat: tmp/*.org: Datei oder Verzeichnis nicht gefunden
> rm: Entfernen von =BBtmp/*.org=AB nicht m=F6glich: Datei oder Verzeichnis=
 nicht gefunden
>  FAILED due to differences in output
> testing t8.m... FAILED due to differences in output
>=20
> > doxygen --version
> 1.3.9.1-20041206

Hmm, could you retry with the new version (1.3.9.1-20041213). The
regression tests
work fine with valgrind for me (I'm using version 2.2.0 of valgrind).

Regards,
  Dimitri

Re: [Doxygen-develop] feature suggestion

[<at...@ko...>]

Maybe you can add an option GROUP_COLLABORATION_GRAPH_MERGE_ARROWS wich us=
e
HTML-like labels=2E

Then function becomes :

void DotGroupCollaboration::Link::WriteLink( QTextStream &t, int& curNodeI=
d
)
{
    const char* linkTypeColor[] =3D {
             "darkorchid3"
            ,"orange"
            ,"blueviolet"
            ,"darkgreen"  =20
            ,"firebrick4" =20
            ,"grey75"
            ,"midnightblue"
        };
    const QCString defaultArrowStyle =3D "dir=3D\"none\", style=3D\"dashed=
\"";
    QCString tmpString;
    if(!Config_getBool("GROUP_COLLABORATION_GRAPH_MERGE_ARROWS")) //
separate arrows
    {
        for( uint j =3D 0; j < labels=2Ecount(); ++j )
        {
            t << " Node" << pNStart->number();
            t << " -> ";
            t << " Node" << pNEnd->number();
            t << " [label=3D\"" << *labels=2Eat(j) << "\"";
            if( !urls=2Eat(j)->isEmpty() )
                t << ", URL=3D\"" << *urls=2Eat(j) << "\"";
            tmpString =3D defaultArrowStyle;
            switch( eType )
            {
                case thierarchy :
                    tmpString =3D "dir=3D\"back\", style=3D\"solid\"";
                default :
                    t << ", color=3D\"" << linkTypeColor[(int)eType] << "\=
"";
                    break;
            }
            if( !tmpString=2EisEmpty() )
                t << ", " << tmpString;
            t << "];" <<endl;
        } // for( uint j =3D 0; j < labels=2Ecount(); ++j )
    } //=20
    else
    { // grouped links=2E
        t << " Node" << pNStart->number();
        t << " -> ";
        t << " Node" << pNEnd->number();
        t << " [shape=3Dplaintext, label=3D<<TABLE BORDER=3D\"0\"
CELLBORDER=3D\"0\">";

        for( uint j =3D 0; j < labels=2Ecount(); ++j )
        {
            t << "<TR><TD ";
            if( !urls=2Eat(j)->isEmpty() )
                t << "HREF=3D\"" << *urls=2Eat(j) << "\"";
            t << ">" <<*labels=2Eat(j) << "</TD></TR>";
        }
        t << "</TABLE>>";
        tmpString =3D defaultArrowStyle;
        switch( eType )
        {
            case thierarchy :
                tmpString =3D "dir=3D\"back\", style=3D\"solid\"";
            default :
                t << ", color=3D\"" << linkTypeColor[(int)eType] << "\"";
                break;
        }
        if( !tmpString=2EisEmpty() )
            t << ", " << tmpString;
        t << "];" <<endl;
    }
}

Message Original:
-----------------
A partir de: Dimitri van Heesch dimitri@stack=2Enl
Date: Sun, 12 Dec 2004 20:33:29 +0100
A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


On Sun, Dec 12, 2004 at 12:17:35PM -0500, atandin@komodosoft=2Ecom wrote:
> Added rtf and latex support=2E
> Tested on RTF only=2E

Thanks,

I'm afraid I have to change the HTML-like labels for now into the simpler=20=

escaped-string labels because the HTML labels made dot crash (on Mac OS X,=
=20
with GraphViz-2=2E0), on Linux with version 1=2E17 there was no problem=2E=
 Older
versions do not support HTML-like labels at all, so using them in doxygen
at this stage is asking for problems=2E

Regards,
  Dimitri




--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E

Re: [Doxygen-develop] feature suggestion

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

On Sun, Dec 12, 2004 at 12:17:35PM -0500, at...@ko... wrote:
> Added rtf and latex support.
> Tested on RTF only.

Thanks,

I'm afraid I have to change the HTML-like labels for now into the simpler 
escaped-string labels because the HTML labels made dot crash (on Mac OS X, 
with GraphViz-2.0), on Linux with version 1.17 there was no problem. Older
versions do not support HTML-like labels at all, so using them in doxygen
at this stage is asking for problems.

Regards,
  Dimitri

Re: [Doxygen-develop] feature suggestion

[<at...@ko...>]

Added rtf and latex support=2E
Tested on RTF only=2E

Message Original:
-----------------
A partir de: Dimitri van Heesch doxygen@gmail=2Ecom
Date: Sun, 12 Dec 2004 14:20:53 +0100
A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


On Sun, 12 Dec 2004 07:35:56 -0500, atandin@komodosoft=2Ecom
<atandin@komodosoft=2Ecom> wrote:
> Yes, it does=2E
> I've used linkable edge labels in the group collaboration graph=2E Even =
with
> multiple labels on edges=2E
> Did you take a look on the patches I've send you ?

I'm integrating them now=2E I've noticed you only looked at the HTML
output, not the
LaTeX and RTF output, so I have to check if your approach works there as
well
(not that links are required for these formats, but at least a graph
must still be generated
and look ok)=2E

Regards,
  Dimitri


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users=2E=

Discover which products truly live up to the hype=2E Start reading now=2E=20=

http://productguide=2Eitmanagersjournal=2Ecom/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop@lists=2Esourceforge=2Enet
https://lists=2Esourceforge=2Enet/lists/listinfo/doxygen-develop



--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E

Re: [Doxygen-develop] feature suggestion

[<at...@ko...>]

But, in an other hand=2E=2E=2E if no links are avable for those format, th=
en only
the picture will be used I guess=2E Link are in the =2Emap file so I think=
 It
should not disturb Latex or rtf outputs=2E

Message Original:
-----------------
A partir de: atandin@komodosoft=2Ecom atandin@komodosoft=2Ecom
Date: Sun, 12 Dec 2004 10:46:35 -0500
A: doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


I thought dot graph where not produced for those format=2E=2E=2E oupss=2E
Do you want me to change the code to desible links (and so use \n for
labels) for those format ?

Message Original:
-----------------
A partir de: Dimitri van Heesch doxygen@gmail=2Ecom
Date: Sun, 12 Dec 2004 14:20:53 +0100
A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


On Sun, 12 Dec 2004 07:35:56 -0500, atandin@komodosoft=2Ecom
<atandin@komodosoft=2Ecom> wrote:
> Yes, it does=2E
> I've used linkable edge labels in the group collaboration graph=2E Even =
with
> multiple labels on edges=2E
> Did you take a look on the patches I've send you ?

I'm integrating them now=2E I've noticed you only looked at the HTML
output, not the
LaTeX and RTF output, so I have to check if your approach works there as
well
(not that links are required for these formats, but at least a graph
must still be generated
and look ok)=2E

Regards,
  Dimitri



--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users=2E=

Discover which products truly live up to the hype=2E Start reading now=2E=20=

http://productguide=2Eitmanagersjournal=2Ecom/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop@lists=2Esourceforge=2Enet
https://lists=2Esourceforge=2Enet/lists/listinfo/doxygen-develop



--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E

Re: [Doxygen-develop] feature suggestion

[<at...@ko...>]

I thought dot graph where not produced for those format=2E=2E=2E oupss=2E
Do you want me to change the code to desible links (and so use \n for
labels) for those format ?

Message Original:
-----------------
A partir de: Dimitri van Heesch doxygen@gmail=2Ecom
Date: Sun, 12 Dec 2004 14:20:53 +0100
A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


On Sun, 12 Dec 2004 07:35:56 -0500, atandin@komodosoft=2Ecom
<atandin@komodosoft=2Ecom> wrote:
> Yes, it does=2E
> I've used linkable edge labels in the group collaboration graph=2E Even =
with
> multiple labels on edges=2E
> Did you take a look on the patches I've send you ?

I'm integrating them now=2E I've noticed you only looked at the HTML
output, not the
LaTeX and RTF output, so I have to check if your approach works there as
well
(not that links are required for these formats, but at least a graph
must still be generated
and look ok)=2E

Regards,
  Dimitri



--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E

Re: [Doxygen-develop] feature suggestion

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

On Sun, 12 Dec 2004 07:35:56 -0500, at...@ko...
<at...@ko...> wrote:
> Yes, it does.
> I've used linkable edge labels in the group collaboration graph. Even with
> multiple labels on edges.
> Did you take a look on the patches I've send you ?

I'm integrating them now. I've noticed you only looked at the HTML
output, not the
LaTeX and RTF output, so I have to check if your approach works there as well
(not that links are required for these formats, but at least a graph
must still be generated
and look ok).

Regards,
  Dimitri

Re: [Doxygen-develop] feature suggestion

[<at...@ko...>]

Yes, it does=2E
I've used linkable edge labels in the group collaboration graph=2E Even wi=
th
multiple labels on edges=2E
Did you take a look on the patches I've send you ?

Would you like me to code the same stuff for the class collaboration graph=
s
?

Message Original:
-----------------
A partir de: Dimitri van Heesch dimitri@stack=2Enl
Date: Sat, 11 Dec 2004 21:12:19 +0100
A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
Sujet: Re: [Doxygen-develop] feature suggestion


On Sat, Dec 11, 2004 at 06:42:24AM -0500, atandin@komodosoft=2Ecom wrote:
> I was thinking about the arrows=2E
>=20
> "Of the latter I'm not so sure=2E" ?

After rereading http://www=2Egraphviz=2Eorg/cvs/doc/info/attrs=2Ehtml#d:UR=
L
I think dot *does* support clickable edge labels (I was under the
impression=20
it didn't, hence my remark)=2E This makes it a good idea to use this featu=
re=2E

Regards,
  Dimitri

>=20
> Message Original:
> -----------------
> A partir de: Dimitri van Heesch dimitri@stack=2Enl
> Date: Sat, 11 Dec 2004 10:46:11 +0100
> A: atandin@komodosoft=2Ecom, doxygen-develop@lists=2Esourceforge=2Enet
> Sujet: Re: [Doxygen-develop] feature suggestion
>=20
>=20
> On Fri, Dec 10, 2004 at 12:19:06PM -0500, atandin@komodosoft=2Ecom wrote=
:
> > What do you think about creating hyperlink on class attributes in the
> > class' collaboration graphs ?
>=20
> You mean the attributes that appear when UML_LOOK is enabled or the
> ones along the arrows?
> =20
> It makes sence indeed to link them to the documentation, provided=20
> there is documentation of course and the dot tool supports such links=2E=

> Of the latter I'm not so sure=2E
>=20
> Regards,
>   Dimitri
>=20
>=20
>=20
> --------------------------------------------------------------------
> mail2web - V?rifiez votre courrier ?lectronique depuis le web sur
> http://mail2web=2Ecom/ =2E
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=2E=

> Discover which products truly live up to the hype=2E Start reading now=2E=

> http://productguide=2Eitmanagersjournal=2Ecom/
> _______________________________________________
> Doxygen-develop mailing list
> Doxygen-develop@lists=2Esourceforge=2Enet
> https://lists=2Esourceforge=2Enet/lists/listinfo/doxygen-develop


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users=2E=

Discover which products truly live up to the hype=2E Start reading now=2E=20=

http://productguide=2Eitmanagersjournal=2Ecom/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop@lists=2Esourceforge=2Enet
https://lists=2Esourceforge=2Enet/lists/listinfo/doxygen-develop



--------------------------------------------------------------------
mail2web - V=E9rifiez votre courrier =E9lectronique depuis le web sur
http://mail2web=2Ecom/ =2E

Re: [Doxygen-develop] Const test cases working fine -- Re: [Doxygen-users] Doxygen-1.3.9.1-20040612 in CVS

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

> > I've working on a simple regression test suite myself (see attachment).
> > I think it is indeed a good idea to collect more test cases so any
> > regression is found quickly.
> >
> > I've added your const functions now, and any new test cases or
> > improvements to the scripts are welcomed.
> Hi I will test it and try to combine it with my work also.
> 
> What does your test suit do?
>  ++ Check if the doxygen xml output has change since the last time
>   -- Check if the doxygen output has some specific result!
> 

From the README:

This directory contains a number of test source files and two scripts
- update.sh: Updates the reference output for each test. The XML output is
             used for this, as this doesn't contain any layout specifics.
             This should typically be done once using a version of doxygen 
             that is known to be good.
- check.sh:  Runs each test and checks the output against the last updated
             version. Warnings reported by doxygen or differences in the
             output produced make a test fail. Differences are placed in a
             diff file with the name of the test file.

So you basically run update.sh once (and again if some features are
add that result in
different output). And then use check.sh to verify if the results are
still the same by
comparing the XML output) and if doxygen doesn't produce any warnings.

Regards,
  Dimitri

Re: [Doxygen-develop] Const test cases working fine -- Re: [Doxygen-users] Doxygen-1.3.9.1-20040612 in CVS

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

Hi

Am Samstag, 11. Dezember 2004 22:28 schrieb Dimitri van Heesch:
> On Fri, 10 Dec 2004 14:28:31 +0100, Enno Bartels
>
> <enn...@t-...> wrote:
> > Hi
> >
> > Am Montag, 6. Dezember 2004 19:38 schrieb Dimitri van Heesch:
> > ...
> >
> > > + BUG: id 157085: Autolinks for const/volatile operators didn't work.
> > > + BUG: id 157433: Multi-variable declarations were not parsed
> > > properly.
> >
> > ...
> > Thank you very much for solving this nasty bug.
> > Now I can use "const" without breaking the doxy docu!
> >
> > I think this has even solved the following bug
> > http://bugzilla.gnome.org/show_bug.cgi?id=120389
> >
> > I did test this with the following test cases and
> > everyone was working fine (for the first time) !
> >
> > 1.  int charp_fctCall (char *)
> > 2.  int charpconst_fctCall (char *const)
> > 3.  int constcharp_fctCall (const char *)
> > 4.  int constcharpconst_fctCall (const char *const)
> > 5.  int constconst_fctCall (MyType *const)
> > 6.  int constcharpconst_fctCall (const char *const)
> > 7.  int intp_fctCall (int *)
> > 8.  int intpconst_fctCall (int *const)
> >
> > On my CVS copy of doxygen I do have an additional test
> > directory for my test cases. And with "make test" it
> > will generate the docu and check if it
> > has the right elements inside.
> >
> > Maybe it would be wise to add my and even more
> > test cases to the doxgen cvs version. So a new version
> > of doxygen could be tested automaticly for old/new
> > problems very easyly!
>
> I've working on a simple regression test suite myself (see attachment).
> I think it is indeed a good idea to collect more test cases so any
> regression is found quickly.
>
> I've added your const functions now, and any new test cases or
> improvements to the scripts are welcomed.
Hi I will test it and try to combine it with my work also.

What does your test suit do?
 ++ Check if the doxygen xml output has change since the last time
  -- Check if the doxygen output has some specific result!
  ?

Thanks for listening
Enno

Re: [Doxygen-develop] Const test cases working fine -- Re: [Doxygen-users] Doxygen-1.3.9.1-20040612 in CVS

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

On Fri, 10 Dec 2004 14:28:31 +0100, Enno Bartels
<enn...@t-...> wrote:
> Hi
> 
> Am Montag, 6. Dezember 2004 19:38 schrieb Dimitri van Heesch:
> ...
> > + BUG: id 157085: Autolinks for const/volatile operators didn't work.
> > + BUG: id 157433: Multi-variable declarations were not parsed
> > properly.
> ...
> Thank you very much for solving this nasty bug.
> Now I can use "const" without breaking the doxy docu!
> 
> I think this has even solved the following bug
> http://bugzilla.gnome.org/show_bug.cgi?id=120389
> 
> I did test this with the following test cases and
> everyone was working fine (for the first time) !
> 
> 1.  int charp_fctCall (char *)
> 2.  int charpconst_fctCall (char *const)
> 3.  int constcharp_fctCall (const char *)
> 4.  int constcharpconst_fctCall (const char *const)
> 5.  int constconst_fctCall (MyType *const)
> 6.  int constcharpconst_fctCall (const char *const)
> 7.  int intp_fctCall (int *)
> 8.  int intpconst_fctCall (int *const)
> 
> On my CVS copy of doxygen I do have an additional test
> directory for my test cases. And with "make test" it
> will generate the docu and check if it
> has the right elements inside.
> 
> Maybe it would be wise to add my and even more
> test cases to the doxgen cvs version. So a new version
> of doxygen could be tested automaticly for old/new
> problems very easyly!

I've working on a simple regression test suite myself (see attachment).
I think it is indeed a good idea to collect more test cases so any 
regression is found quickly. 

I've added your const functions now, and any new test cases or 
improvements to the scripts are welcomed.

Regards,
   Dimitri

[Doxygen-develop] Re: SHOW_DIRECTORIES and EXTRACT_ALL

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

On 11.12.2004 21:05:58 Dimitri van Heesch wrote:
> This should already work better in the more recent CVS versions.

> Regards,
>   Dimitri

OK thanks. I updated to the newer version - now it works as expected.

Regards,

    Martin

Re: [Doxygen-develop] feature suggestion

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

On Sat, Dec 11, 2004 at 06:42:24AM -0500, at...@ko... wrote:
> I was thinking about the arrows.
> 
> "Of the latter I'm not so sure." ?

After rereading http://www.graphviz.org/cvs/doc/info/attrs.html#d:URL
I think dot *does* support clickable edge labels (I was under the impression 
it didn't, hence my remark). This makes it a good idea to use this feature.

Regards,
  Dimitri

> 
> Message Original:
> -----------------
> A partir de: Dimitri van Heesch di...@st...
> Date: Sat, 11 Dec 2004 10:46:11 +0100
> A: at...@ko..., dox...@li...
> Sujet: Re: [Doxygen-develop] feature suggestion
> 
> 
> On Fri, Dec 10, 2004 at 12:19:06PM -0500, at...@ko... wrote:
> > What do you think about creating hyperlink on class attributes in the
> > class' collaboration graphs ?
> 
> You mean the attributes that appear when UML_LOOK is enabled or the
> ones along the arrows?
>  
> It makes sence indeed to link them to the documentation, provided 
> there is documentation of course and the dot tool supports such links.
> Of the latter I'm not so sure.
> 
> Regards,
>   Dimitri
> 
> 
> 
> --------------------------------------------------------------------
> mail2web - V?rifiez votre courrier ?lectronique depuis le web sur
> http://mail2web.com/ .
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] SHOW_DIRECTORIES and

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

On Sat, Dec 11, 2004 at 02:37:05PM +0100, Martin Fuchs wrote:
> Hello,
> 
> I tried using the new option "SHOW_DIRECTORIES=yes" with Doxygen 1.3.9.1.
> It seems, this does work only together with "EXTRACT_ALL=yes".
> If "EXTRACT_ALL=no", files like "dir_0000xx.html" are written.
> But there are missing the file "dirs.html" and a link to this in the generated HTML menu.
> 
> Is this the intent, or is this a bug?  ;-)

This should already work better in the more recent CVS versions.

Regards,
  Dimitri

[Doxygen-develop] SHOW_DIRECTORIES and

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

Hello,

I tried using the new option "SHOW_DIRECTORIES=3Dyes" with Doxygen 1.3.9.1.
It seems, this does work only together with "EXTRACT_ALL=3Dyes".
If "EXTRACT_ALL=3Dno", files like "dir_0000xx.html" are written.
But there are missing the file "dirs.html" and a link to this in the genera=
ted HTML menu.

Is this the intent, or is this a bug?  ;-)

Regards,

   Martin