LaKademy, Hierarchical Edge Bundles, and KDevelop


Hi there,

Yes, LaKademy is over. They were days of hard work, meeting old and new friends, and having much fun while realizing how far those crazy guy's imagination can go. I'd say it was a great summit and, when compared to first (and only one so far) Akademy-BR carried out in 2010, it's a clear evidence we are getting there in the effort of building a strong and mature KDE community in Latin America. Henrique and Camila managed to book a lovely hostel in Porto Alegre and, even though I usually don't get used to traditional food in Rio Grande do Sul, we were all nicely accommodated through these days. Sorry for haven't posted before, I'm rather taking an "all-in-one" approach to report LaKademy outcomes.

LaKademy brought together 19 participants, including developers, translators, designers, and promo people. Trying to keep this post simple and concise, I'll briefly enumerate major LaKademy outcomes related to artwork and localization, promo, and developing. In particular, my own developing outcomes are presented later.

Artwork and Localization Outcomes

It seems that Tomaz has unintentionally taken over the task of bringing new designers for KDE here in Brazil. The difficulty arises from the proprietary background designers usually possess and then excuses of reduced productivity are a major obstacle to migrate to open source tools. At LaKademy, Tomaz, Manu, and Fabiana discussed current artwork needs of KDE and had a conference call with Nuno, trying to clarify tool differences and line up goals. Actually, I still notice that designers are maybe the most difficult people to be aware of real underpinnings of free software contribution and we haven't found the means to provide that to them yet. Rocs' "weird lemon add node icon" :) is still there but hopefully some artwork fresh blood will help us to get rid of it.

Aracele, Diogo, Camila, and Henrique have been working hard :) in userbase and techbase localization. Techbase pt_BR localization coverage run from 6% to 30% by the end of LaKademy.

Promo Outcomes

The promo meeting at LaKademy took an entire morning with discussion topics like: lessons learned from previous promo efforts, KDE Brazil/LatAm web presence, upcoming FLOSS conferences, and promo material manufacturing. Expected short-term accomplishments include:

• KDE Brazil | Argentina | Peru ? | LatAm web site (re)design. We aren't sure about the need for a KDE LatAm web site (that discussion is going to continue on kde-latam mailing list) but we all agree on a re-design of KDE Brazil website. I've just noticed that ar.kde.org redirects to a drupal-based website.

• KDE LatAm Webcasts. Chicão has already pushed some tutoriais about making video tutorials about KDE.

• "KDE Masters of Latin-America" (TM by Guilhermo Amaral) :) Podcasts.

• Git repository for standard KDE kick-ass presentations (btw, how to create translatable LibreOffice documents ?).

• "Myths and Facts about KDE Technology" marketing campaign. The intended audience is those people who still have a KDE Plasma 4.0-4.2 conceiving and haven't given it another try since then. Our participation in FLISOL, while at LaKademy, have confirmed that we need such campaign.

• Upcoming FLOSS conferences in Latin-America. A bunch of FLOSS conferences (Congresso da SBC/ENECOMP, FISL, Latinoware, GNUGraph, FSLDC, Hack'nRio, LinuxWeek (Peru), CaFeCon (Argentina), Software Freedom Day, Campus Party Peru, Campus Party Pernambuco) are going to happen and we need to articulate the KDE participation in those.

• In particular, we considered that a "KDE Day" (in a format similar to FLISOL) taking place simultaneously in various Latin-America cities might be a fruitful marketing strategy, even though with minimal technical outcomes. Initial tentative date is 27th October, just one week after Latinoware (so that we could do some announcement there).

• Quite minimal, enduser-oriented KDE portal. Something like descubra.kde.org (discover.kde.org) would provide, with a minimal simplified mapsite, the general reasons to use KDE and how to get it running in an easy way. That would support a KDE promotion effort in those fields aren't related to technology at all. We see a huge potential of KDE adoption in Latin America and maybe we are driven our efforts to a most restricted audience.

Developing Outcomes

A number of developers were in LaKademy making improvements in projects like Rocs, KMyMoney, Plasma Network Management, Cantor, Digikam, KDevelop, Amarok, Plasma Active, and Telepathy. We had roughly 18 bugs fixed in Rocs by Tomaz and Wagner, Vitor has been working on a kipi plugin, Ronny worked in ports of KDE Games to Qt Quick, Arthur and Lamarque managed to have a working pilot for a new QML-based Plasma Network Management (part of his GSoC project), Filipe has started a new Python backend for Cantor, Alvaro has fixed bugs in KMyMoney, Lucas is finding his way towards a GSoC project in Amarok, Luis has made some improvements in Spinet architecture and GUI, and Chicão (who unfortunately couldn't attend LaKademy) is already working on his GSoC project in Krita. As for myself, I dedicate my LaKademy attendance also to have hierarchical edge bundles working in KDevelop. Keep reading ...

Compound Graphs and Hierarchical Edge Bundles

Information/Software Visualization techniques has been providing increasingly powerful paradigms for understanding huge amount of data and that certainly would help to support more effectively software design and evolution activities. In particular, a number of techniques for visualizing tree structures have been proposed in last years:


An even more interesting scenario is the use of compound graphs to represent adjacency relationships (between tree's leaves) along with hierarchical relationships already provided by trees. One should consider, for example, professors hierarchically grouped by departments and also having adjacency relationships when co-authoring a paper or co-mentoring a student. In a software development project, that would easily be represented by hierarchically grouped artifact containments (like namespaces, classes, functions, etc) and some dependency relationship (for example, uses) between classes or functions. The use of arrows to represent adjacency relationship directions would produce more visual clutter so edges are drawn from source (green) to target (red).


A common issue when visualizing such compound structures is the visual clutter you rapidly come up even for small sized graphs. A pretty interesting paper by Danny Holten, "Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data", proposes a strategy for compound graph visualization which reduces visual clutter while still highligths implicit adjacencies in higher level containments:


So at the end of LaKademy I wanted to have at least the radial layout with edge bundles running in KDevelop.

libgraphicstreeview

Hierarchical edge bundles in mirrored radial tree view (rightmost view above) were implemented in a separated library so that other applications could use it for visualizing tree data other than KDevelop projects. Classes were designed to easily support the future inclusion of new tree layouts while reusing the edge bundle generation part. The RadialGraphicsTreeView class (first implementation of IGraphicsCompoundTreeView) works with any tree-based Qt model (representing the hierarchical model) and accepts a second table-based Qt model representing the adjacency relations. Any tree-based and table-based Qt models representing hierarchical and adjacency relations, respectively, should be correctly visualized by libgraphicstreeview. A number of parameters (node radius, inter level spacing, inter span spacing, bundling strength, mirroring radius increment, etc) can be used to tailor the visualization for specific purposes.

libgraphicstreeview provides a demo application which visualizes a file system Qt model populated with a dummy adjacency model and allows the user to play with visualization parameters:


Check out the libgraphicstreeview demo app video:

Whilst already functional, some improvements and new features must still be done in libgraphicsview:

• More realistic implementation of interpolated B-splines. Current implementation is based on Qt's quad and cubic splines but knot vectors should be used to support smoother and more bundled adjacency edges.
• Background generation of graph layout and edge bundles. QtConcurrent and mapreduce would be a potential support technology for that.
• Filtering of adjacency edges by picking them with a linear selection.
• General profiling and optimization.

KDevelop, Control Flow Graphs, and Hierarchical Edge Bundles

Some years ago I developed the control flow graph plugin for KDevelop. It's still in playground and, although functional, it suffers from the following drawbacks (part of the reasons for still being in playground):

• Actually it doesn't provide control flow graphs in its original definition. It rather provides a consolidated control flow graph at the least abstraction level supported by DU-chain.
• It doesn't support efficient visual escalability. We couldn't represent large control flow graphs in a restricted region of screen.
• It needs a major refactoring to separate some concerns and make evolution easier.
• All its cognitive information about a KDevelop project can also be carried out by a mirrored radial with hierarchical edge bundles while still solving the previously cited issues. Actually I still need further elaborate that to decide about the future of control flow graphs in KDevelop.
  Hierarchical edge bundles in KDevelop already represents the hierarchical project structure but it's still using a dummy model for adjacency relations. The hierarchical model is quite similar to the ClassModel class used in classbrowser plugin, but (at least by now) there is no need to retrieve information about attributes, and base/derived classes. I'm not an expert in KDevelop architecture but it seems plugins aren't able to communicate other than by means of KDevIDEExtension. Maybe Aleix or Milian could have any hint for properly sharing ClassModel. :)

Navigation from radial tree visualization to code still needs to be done, as well as a picking mechanism for filtering adjacency edges of interest. Checkout the following video showing libgraphicstreeview as a KDevelop plugin.

Several future improvements could also be done, such as the assignment of metrics (for example, the CK metrics suite) to visual attributes like color, opacity, size, speed of animation, etc. Evolution information also provides some interesting information about software architecture and software development processes.


Check out KDevelop's bundled tree view plugin video:

I'm watching myself for having a couple hours per week to improve libgraphicstreeview and KDevelop's bundled tree view. Of course, any help is quite appreciated since I'm still bogged down with PhD duties. You can git clone source code for libgraphicstreeview and KDevelop plugin at:

git@git.kde.org:scratch/sandroandrade/libgraphicstreeview.git
git@git.kde.org:scratch/sandroandrade/kdev-bundled-tree-view.git

See you !