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