7. Existing plugins

7.1. Transformations

7.1.1. CompatGroup

This transformation is a temporary one, allowing to use existing project classes (defining groups through a filelabel() method), to be used in the new design.

7.1.2. Consolidate

Standard group transformations may not include all nodes from a graph into group nodes. Thus, a group graph does not as such describe all the files fed into the tool.

This transformation will merge graphs describing different grouping levels, so that each node from the lowest-level graph requested will be represented by a node in the result graph: if it is part of a group, the highest-level group of which it is a member will be appear, if not the node itself will appear instead.

7.1.3. TransitiveReduction

Dependency graphs are often hard to read because of the large number of edges. Since the depndency relation can be seen as being transitive (if A depends on B and B on C, then A depends on C), we can make the graph more readable by not drawing those edges which the transitivity property makes redundant. This is what this transformation achieves.

7.2. Styles

7.2.1. Node styles

7.2.1.1. PerGroup

Allows to set style attributes (eg. color) based on group membership.

7.2.1.2. GroupStats

Adds in group nodes some statistics: the number of nodes that make up this group, and the number of edges between those member nodes (ie. dependencies internal to the group). Note that this is relative to the group-level immediately below in the group hierarchy, NOT to the files themselves - parameters will be added later to makes this more customizable.

7.2.2. Edge styles

7.2.2.1. WeightLabel

Adds a label on edges, showing how many dependencies between the lowest-level nodes (eg. effective number of include relationship between files) are represented by each edge. Contrast this with the intra-group counts currently reported by GroupStats on nodes.

7.3. Project classes

Note

The concept of project classes will most probably be replaced by project files in the near future, as functionality currently located there will move into more adequate areas.

7.3.1. class "default"

As implied by its name, it is the one which will be used unless you use the --class option. Although it is the default one, it may still be quite rough at the moment, still using some ad-hoc heuristics, and will be improved in the near future. Here are its main characteristics:

  • looks at C-style #include lines

  • creates level-1 groups for all files sharing the same path and (disregarding the suffix) filename. Eg, files "foo/bar.c" and "foo/bar.h" would be grouped in a "foo/bar" level-1 group. In clear, it won't connect include files if they are all located in an include/ directory.

  • creates by-directory level-2 groups. Eg. in the above example, a group "foo" would exist at level-2.

7.3.2. class "uniqueincludes"

Built on top of the default class, it is meant for projects where file names are kept unique across all directories. If the ad-hoc #include processing of the default class does not suit your project, it is the only out-of-the-box alternative available today. Here are its main characteristics:

  • provides a single grouping level based on filenames, disregarding all the directory hierarchy.

Note that it is not meant for general use, as:

  • it will group any files with the same name in the same level-0 group, possibly causing confusion.

  • it does not make any directory name appear in the node names