Customize diagrams with images

Continuing from the example of our previous blog post on House of Cards, we’ll see today how one can customize the elements of diagrams by using pictures.

Per-diagram instance customization

In a Sirius based editor, the style of each diagram element can be customized. This customization can be applied from:

  • the tool bar:

  • the Appearance tab of the property view:

  • the Diagram menu:

  • the contextual menu Format:

The elements you can customize are:

  • container: background color, background style, border size, foreground color, label alignment, label size, label format and workspace image.
  • node: border size, color, label alignment, format, position, size and workspace image.
  • edge: the folding style, the color, the label alignment, format, position and size, the line and routing style, the size and the target and source arrow.

If we set a workspace image on the Influence diagram resulting from the tree layout blog post, we are able to see Frank Underwood’s face instead of a simple white square.

These customizations can be reset using:

  • the Reset style customization button available in the Appearance tab of the property view :

  • in the diagram editor tool bar :

Thanks to this feature each user can customize existing diagrams in any Sirius based modeler. The problem with this solution is that if you create another diagram, the default style will be applied, and we would no longer see Frank’s beautiful face. This method is only useful to customize a specific instance of a diagram.

Using workspace image style

If instead of having customization specific to a given instance, we would like all diagrams of a certain type, what we need to do is to provide the image during the diagram specification phase.

In order to get the image on every new diagram, we need to provide it at the diagram specification phase. To do so, after reopening the houseofcards.odesign, we need to update the Influence diagram description to use a workspace image in a conditional style to represent Frank.

From now on, everytime an Influence diagram is created, Frank’s and Linda’s faces will automatically be associated to the relevant diagram elements.

What is problematic with this solution is that we need to create a conditional style for each character. As there are around 50 different characters in the House of Cards series, it is not a very practical solution.

Specify style custom images

Fortunately, Sirius provides another way to achieve that. We want to provide all the images in a specific folder and have Sirius select the right one according to the picture’s name. This can easily be done by using the style customizations.
We modify our mapping to specify a workspace image style.

We provide a new style customization:

And a new property customization by expression:

All the pictures are stored in an images folder.

Then we specify that the style to customize is the workspace image previously defined.
This style customization must be applied on PersonWorkspaceImage and we want to customize the workspacePath property:

To retrieve the value of the workspacePath, we call a Java service getImage which returns the image path from the person name:

Finally, when we reopen our example, we get a shinier diagram this time with everybody associated to his picture.

And now if I update the name of a character, I get automatically the associated picture. John Doe is represented by the default image and we see Zoe’s lovely face.

With the next Sirius 3.0 version, if you use images with a transparent background, the edges will follow the image.

The sample code from this example is available on github:

The Tree Layout Secret

A recurring problem when developing a graphical modeler is providing the right layout. The advantage with Sirius is it provides you with a default algorithm that performs an automatic layout of all the elements on a diagram.

To illustrate the Sirius’ layout capabilities imagine that we want to visualize the hierarchy of characters in the US TV series House Of Cards. To do this we define the following metamodel:

First, we used Sirius to create a diagram representing the Persons.

Each person is represented by a white square with his or her name on it.

By default Sirius lays out nodes from left to right and what we now have is a flat diagram, with each person on exactly the same level.

However what we want to see is the White House organizational hierarchy so we need to represent the subordination link. This link is modeled using the dependsOn reference in the metamodel.
Second we define a new relation based edge mapping. This edge will connect Persons, and to find the subordinate we just use the dependsOn reference.

The default layout will automatically present an ordered tree diagram of the White House hierarchy with president Garrett Walker at the top of the diagram and Congressman Peter Russo at the bottom. When you define a relation based edge, Sirius then automatically lays out the elements as an ordered tree diagram by using the dependsOn reference to find the children.

That looks all very well and good. However, supposing that now we want to retain and be able to view our subordination link but also order our nodes according to a different relation. In our metamodel we add another reference influences that represents the influence one person can exert over another. We need to create another kind of diagram with the most influencial person at the top and the most influenced person at the bottom whilst still retaining the former subordination links between the persons.

Great news! This is really easy to implement with Sirius!
If the Sirius default algorithm does not fit your particular needs, you can configure some of the parameters or request alternative algorithms directly within the Sirius specification editor.
You can define either of:

  • A Composite Layout : this must be used to show containment relations. It enables you to specify padding between the different elements and the direction for the default algorithm.
  • An Ordered Tree Layout : this must be used so as to lay nodes as an ordered tree.

These layout algorithms manage only nodes connected by edges, other nodes are lay out from left to right as usual.

The Ordered Tree Layout is what we need for our case.
We defined a new Influence diagram with a Person mapping and a DependsOn mapping. These mappings are exactly the same as with the Hierarchy diagram. The only difference being that we have produced an Ordered Tree Layout.

The Children Expression is used to specify how to retrieve children for each node. In our example we use the influences reference to progress through the model.

Your Node Mapping must specify the mapping that the tree order algorithm is to operate on. In our example we want the algorithm to operate on Person.

Note: the ordered tree layout only works if you have only defined a single kind of node mapping in your diagram specification.

And… Ta-daaah! By defining this new layout you can see the person influencing every other player in the White House is… Frank Underwood, but Shh! That’s a secret ;)

Finally, if you need to go further, you can also provide your own layout algorithm programmatically.

The sample code from this example is available on github :

Sirius posts are coming!

Just to announce that we (I and some Sirius commiters from Obeo) will start a series of posts about some features available in Sirius. For the ones who don’t know, Sirius is an Eclipse project to quickly define multi view workbenches based on DSL with dedicated representations. Sirius is part of the release train since Luna and its version 3.0 will be available with Mars.
A modeling workbench created with Sirius is composed of a set of Eclipse editors which allow the users to create, edit and visualize EMF models.
In the next weeks, you will discover posts about diagram customization, tree layout, SVG images…

Stay tuned!