A complex example for using KLighD technology, the Ptolemy Visualization project is about generating transient views of Ptolemy II models that are easy to browse through. Ptolemy II is an open source program developed at UC Berkeley for experimenting with actor-oriented modelling. Actors are graphical representations of components with a certain functionality that generate output as a function of the inputs they receive. To use the output of one actor as the input of another, actors can be connected by links. A typical Ptolemy model might for instance look like this:

In some respect, Ptolemy models are a typical example of graphical modelling languages:

• Actors are represented as boxes, with edges connecting the actors to each other. The edges are routed orthogonally: each edge segment is aligned either horizontally or vertically.
• Actors can have more than one input, and more than one output. To be able to distinguish the data coming in and going out, inputs and outputs are routed to dedicated connection points, called ports. Thus, links never connect two actors directly, but rather connect them through their ports.
• Actors can contain further models that define their functionality (we call such actors hierarchical actors). To be able to see the model inside an actor, Ptolemy provides the possibility to look inside the actor. This effectively opens a new Ptolemy window displaying the actor's implementation.

However, Ptolemy models have some features that are not that common:

• Ports are not restricted to be either input ports or output ports: they can be both. As a consequence, links are undirected and can transport data in both directions.
• Models have a director that defines the model of computation used to execute the model. In fact, if an actor in turn has another model inside it, that model, too, has a director. One of the research goals of the Ptolemy project is to find out how different models of computation can be composed.
• All edges are part of relations. A relation is a set of edges that are treated as a hyperedge: an edge that connects not two, but arbitrarily many ports.

KLighD Visualization

With our KLighD visualization, we aim to develop a Ptolemy model browser that is particularly good at helping users read through Ptolemy models. It is able to directly open Ptolemy files and display them in a way very similar to what Ptolemy users are used to seeing. The biggest change with respect to how Ptolemy shows models is that our model viewer allows to expand hierarchical actors in-place, without having to open a new window. This helps users understand the context a hierarchical actor is placed in: by understanding where inputs come from and where outputs go to, users also better understand what the hierarchical actor is doing and what it is used for.

This is a screenshot of the model browser displaying the model that Ptolemy showed before, with some actors expanded:

We have also added further features that may be helpful when browsing models:

• Annotations can be shown or hidden.
• A heuristic tries to find out which actor an annotation is providing the documentation for. This is based on the distance between actors and annotations, with a threshold value after which an annotation is considered to stand alone. This attachment between annotations and actors is displayed by a dashed line, and the layout algorithm makes sure the two are placed near each other.
• Relations in Ptolemy are visualized by small diamond-shaped nodes. Often, these are only used to influence the edge routing. Since we use a layout algorithm to route edges properly, these relation vertices are not necessary. We replace all of them by hyperedges and route the edges properly. An option lets you disable this behaviour: then, only relation vertices with exactly one incoming and one outgoing edge are removed and replaced by a simple edge.
• Expanded hierarchical nodes have a background color that gets darker with each level of hierarchy. How dark this color is can be changed to adjust for projectors and printers that are not as good at showing sublte colors.
• The properties of actors and ports are shown as tool tips. This does not include advanced properties, which are those properties that start with an underscore.

How This Stuff Works

All of this functionality is implemented in one main plug-in and two support plug-ins:

• de.cau.cs.kieler.ptolemy.klighd contains the actual transformation that turns Ptolemy files into something we can display with KLighD.
• org.ptolemy contains a reduced Ptolemy version that we use to render actors. Not all actors are available in this distribution.
• org.ptolemy.moml contains an EMF model that we use to load Ptolemy files.

For the rest of this page, we will describe the basics of how the transformation works and the challenges it presented.

Architecture of the Transformation

The transformation is mostly written in Xtend. Its entry point is the PtolemyDiagramSynthesis class, which is registered with KLighD for the visualization of MOML models. It triggers the three different stages of the transformation:

1. The basic transformation. This is what turns a given MOML model into a KGraph model.
2. An optimization step. A direct transformation of the MOML model doesn't give the best results, which makes this postprocessing step necessary.
3. The visualization. This step adds the KRendering information necessary for KLighD to actually display the model.

It would certainly be possible – and perhaps even faster – to combine these stages into one. Doing this, however, would result in code that only John Carmack would understand. And even he would curse reading it.

Generating the Basic KGraph Model

Optimizing the KGraph Model

Adding Rendering Information to the KGraph Model