Multitouch gesture support for Zest graphs

When I read Jan Köhnlein’s post about multitouch gestures support in their graph viewer, I was thinking, these gestures would be a nice addition to the Zest visualization library. In addition to that, it could be my first new feature as a Zest committer, so I opened bug 371152.

So I looked into the multitouch API in SWT (btw. it is really to use, check snippet 353). Luckily, only a gesture listener had to be added, that is already supported by the Zest graph widget.

I thought about what gestures could be universally supported in the Zest graph, and found that scrolling is already supported, magnification is easy to implement, and for rotation I found a possible use.

Today, I finished the implementation, and created a short video presentation that shows the features in action. See the Youtube video:

Additionally, it is possible to replace the built-in gestures by creating the graph with a specific style bit, and adding other gesture listeners manually as below:

//Disabling default gestures
Graph graph = new Graph(parent, ZestStyles.GESTURES_DISABLED);
//Adding own gesture listener
graph.addGestureListener(new GestureListener() {

  public void gesture(GestureEvent e) {
    switch (e.detail) {
      // Do nothing

I believe the base implementation of the gesture support is useful, but I am open to change it if someone has a better idea.

Source code visualisation for my projects

Today I read the announcement of SourceCloud, a new Zest/Cloudio-based visualization for source code. As I like cool visualizations, I tried it out on the open projects I am participating in.At first I created the cloud for the source code of the Debug Visualisation project. Globally it consists of about half Eclipse debugger/UI and Java keywords – as this is quite a small project (about 4 kLOC), this is somewhat expected with 200 words. 1024w, 367w, 1150w" sizes="(max-width: 300px) 85vw, 300px" /> SourceCloud of the Debug Visualisation Project

However, it is interesting, that the strings ‘end_of_line‘ and ‘sp_cleanup‘ found their way in. Luckily, only a few one-character names and numbers are present, meaning, we managed to created longer variable names…

The cloud of the VIATRA2 model transformation framework is more interesting: it is a much larger codebase, developed for several year by around a dozen people. Because of the size I generated the cloud using 300 words, but almost no Java keywords found their way into the graph. 1024w, 333w, 1046w" sizes="(max-width: 300px) 85vw, 300px" /> SourceCloud of the VIATRA2 framework

However, the mandatory comment parts did, e.g. nbsp or the names of some creators. A lot of EMF-specific keywords are also present. They are present because we have quite a large EMF metamodel that provides several hundred generated Java files.

At last, but not least I also checked the cloud of the EMF-IncQuery project. This is smaller, then the VIATRA2 project, but larger then the Debug Visualisation. Additionally, it has a shorter history, but with several key committers. 1024w, 337w, 1043w" sizes="(max-width: 300px) 85vw, 300px" /> SourceCloud of the EMF-IncQuery project

My personal favorite is this diagram, as it shows a lot of nice things: e.g. four digit numbers in large quantities (magic numbers FTW) or the absolute champion string: ‘HUKfyM7ahfg‘. All of them are present in the Ecore Diagram of the defined metamodel (the meaningless string 152 times as a postfix of an identifier 🙂 ). At least, I learned something about the internal model representation of GMF.

And how do your projects look like?