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