jump to navigation

#3: Visualize your code in KDevelop July 21, 2009

Posted by Sandro Andrade in planetkde-sandroandrade.

Hello planet,

Yes, after a hard journey through free software conferences including International Forum on Free Software (FISL) and Gran Canaria Desktop Summit, I’m happy to bring you fresh news about my GSoC project in KDevelop.

As I’ve previously mentioned, not rarely we face the hard task of understanding complex interactions between software modules as a pre-requisite for evolution/maintenance activities. Software Visualization (or Program Comprehension) tools have become a popular and indispensable feature in modern IDEs, mainly when integrated with conventional tools such as code editor, debugger, revision control, and profilers.

In my last post, I’ve presented how control flow graphs between method invocations can be easily created in KDevelop:

Control flow graph between methods

Control flow graph between methods

In more complex systems this can lead to not so useful graphs due to the high ammount of control flow. By showing control flow in a coarse-grained way the developer can be able to visualize interactions between classes:

Control flow graph between classes

Control flow graph between classes

… or even between namespaces:

Control flow graph between namespaces

Control flow graph between namespaces

Regardless of the used control flow mode (methods, classes, or namespaces) fully two-way integration between code editor and control flow graph is already provided. By clicking on a given node code editor is automatically redirected to the method/class/namespace definition (or declaration, in case of external libraries without available .cpp files). This default behaviour can easily be modified by locking the graph while navigating by clicking its nodes.

Ok, so far we have been using a single graph layout algorithm and colouring graph nodes according to their immediate named scope (I mean, class name when visualizing control flow between methods and namespace name when visualizing control flow between classes).

What about clustering nodes by their immediate scope ? The following clustering modes are already working:

  • Clustering by class: methods belonging to the same class are grouped together and interactions arcs are drawn to other class clusters:

Methods clustered by class name

Methods clustered by class name

  • Clustering by namespace: in a similar way, classes can be grouped by their namespace (including Global Namespace):

Methods clustered by namespace name

Methods clustered by namespace name

  • Clustering by project: adhering to KDevelop 4 support for multiple working projects, nodes can also be grouped by project name. This certainly is a quite useful mechanism for understanding system boundaries and its relationships with external libraries and other projects:

Methods clustered by project name

Methods clustered by project name

Control flow mode and clustering mode were designed as orthogonal mechanisms so that (almost-)any (excluding some meaningless) combination can be achieved: control flow between methods clustered by namespace, control flow between classes clustered by project and so on.

Whilst control flow mode is actually a mutually excluding behaviour, clustering modes can be combined to provide a complete structured representation of control flow in the system.

Maybe some developer would be interesting in clustering by class and namespace names:

Combined clustering by class and namespace names

Combined clustering by class and namespace names

… or even by all the available containers:

Combined clustering by class, namespace, and project names

Combined clustering by class, namespace, and project names

At this point, fellow hackers, how does our beloved visualization plugin look like ?­čÖé

Visualization the KDevelop visualization plugin itself

Visualization the KDevelop visualization plugin itself

As I’ve promised you, enjoy our newly created demo video here:

As for the future work, the following features are currently being evaluated:

  • Drawing of incoming arcs: graphs are currently generated from the method containing the cursor and only outcoming arcs are represented. Drawing incoming arcs representing which entities use a given node is a quite important feature;
  • Showing of uses related to a given arc: an arc (or edge) in a control flow graph is generated from one (or possibly many) invocation. Visualizing the invocations that produced that arc can also be a useful feature for software comprehension;
  • Exporting features: currently all control flow graphs can be exported as png images. Using alternative formats as SVG would leverage the afterwards analysis of source code structure;
  • Polymetric visualization: as I’ve promised as a second visualization paradigm in KDevelop 4.

Well, that’s all folks ! Comments are welcome as usual.

See you in the next GSoC update­čÖé


1. paul - July 21, 2009

Why you call this thing “control flow graph” ? IMHO these are “call graphs”.

2. Luiz - July 21, 2009

Amazing! Can’t wait to be able to use it in my projects! Keep up the great work!

3. Tim - July 21, 2009

Wow, wow, double wow.

You have to show this to Cornelius. The KDE SDK needs KDevelop!

4. Thorben - July 21, 2009

Wow this is great!

How does this scale with very large graphs? Is it still responsive? How fast do you lose the overview with these large graphs?


5. Simon Toth - July 21, 2009

It would be great to provide clustering by file. I have a very old, not well documented C project that is using huge amount of global variables. It would be great to visualise relations between files (shared global variables, etc…).

6. boulabiar - July 21, 2009

integrating SVG as an output file, and UML as a standard will make the project even better and better !

7. Tomaz - July 22, 2009

muito bom mesmo sandro.
já estou usando aqui ele no day-to-day no rocs,
qualquercoisa eu aviso pra ti =)

8. Tim - July 24, 2009

BTW Will this work for Python etc as well?

9. Tomaz Canabrava - July 31, 2009

It will work for anything that DUChain supports.

10. tom - August 6, 2009

I think it would look better if the Global namespace items would be drawn right on the grey background instead on a white box like the other namespaces (in Clustering by namespace)

11. Crypto - August 10, 2009

Visualization looks great and promising… It appears to be a kind of merger of the former kscope (the one that used to include graphviz) and kdevelop which has appeared impossible to get so far.

Will this new kdevelop with visualization work for “simple” C based projects as well (so no classes, but much more structs etc.­čśë )

Keep going in this direction.


Sandro Andrade - August 10, 2009

Hy Crypto, yes it will work for simple C based projects and any other project written in any KDevelop-supported programming language.

12. anon - September 19, 2014

Hi, where can I download this plugin?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: