.NetMap

23 Aug, 2008  No Comment  Diagramming

Microsoft released already a while ago the GLEE library as a closed source library for graph layout which you can use for non-commercial purposes for free. Now, more recently, the MS research group also released on CodePlex .NetMap which

…is a pair of applications for viewing network graphs, along with a set of .NET Framework 2.0 class libraries that can be used to add network graphs to custom applications…

The code is partially based on the GLEE library and is well-documented to allow one to extend it with, for example, additional layout algorithms. So, this library could be a good start for a stand-alone component or library for diagramming in general. The only minor point at this moment is the fact that it’s .Net 2.0 code and, hence, GDI+ based. No WPF in sight. Not yet, but who knows…

Large diagrams and layout algorithms in WPF

29 Jul, 2008  2 Comments  Diagramming, GraphSquare

In a previous article I already showed how large diagrams can benefit from layout algorithms. Netron was at the basis of the pretty pictures in this article and it was fairly easy to port the code to WPF, though WPF has some threading intricacies:

There is no noticeable difference between using layout algorithms in WPF and in GDI, the positioning and handling of coordinates is similar. On the other hand, there is a big difference between the responsiveness of WPF. In the examples below I was able to lay out 1500 nodes in less than five seconds but altering the diagram or scrolling produces grinding sounds. Obviously the cause is in the usage of the Control as a base class and the heavy weight of carrying animation, databinding and other stuff which for large diagrams is usually less an advantage. Using the System.Windows.Shapes namespace of .Net would be a better choice for big diagrams and layout.

When it comes to diagramming there is always a choice between sacrificing features or sacrificing scalability. There is also the balance between making a general purpose control and implementing stuff for a particular target group. For example, if you are interested in HMI diagrams you are not interested in large diagrams and vice versa. As well as the choices in what to deliver as shape libraries. Because it’s really hard to enable users to create shapes without understand the API (or opening the source code) one has to deliver a common set of shape libraries, but of course everyone has particular needs. If you use Visio you can easily add new shape to libraries but I wonder whether the serialized shapes are just groupings of predefined elements or really standalone blocks. In that respect one can consider grouping of basic shapes a good solution for a wide audience. I think, however, that for custom diagramming solutions and integrations one inevitably flows into custom code and custom diagramming controls. Diagramming software cannot be separated from consultancy unless you constraint yourself to the average (common) needs.

But anyway, in April 2006 I produced large diagrams in Netron and here they are again but based on pure WPF code. The first screenshot  represents randomly generated nodes on the diagramming surface.

The radial produce in less than three seconds a beautiful set of concentric nodes:

The balloon tree layout produced a rather dispersive diagram is the same time span:

Finally, the force directed layout produced the expected organic layout in tick more than five seconds:

It’s very unusual

3 Jul, 2008  3 Comments  Fun

Can’t help sharing this one, can’t even believe the whole thing wasn’t set up. Politics :)


The front fell off… from David Hegarty on Vimeo.

GraphSquare architecture IV

27 Jun, 2008  No Comment  Diagramming, GraphSquare, WPF

In the previous part we talked a bit about tools and surface mechanisms, this time we’ll talk about the serialization of diagrams, which is a huge topic on its own and a complicated one at times too. You probably know that serialization is related to copy/paste, saving things to files, the property grid, drag-drop… In fact serialization is pretty much everywhere: WCF services, Windows workflows, P2P communication and more. The .Net frameworks gives you a wealth of mechanisms to help you serialize things with various levels of sophistication: attributes (Serializable, DataContract,…), interfaces (ISerializable, IXmlSerializable…) and formatters (binary, soap, xml…) together with whole namespaces full of utility classes. In the next few paragraphs I’ll review first some basics of serialization, explain the internal structure of our (MVC) Model, highlight the problems you encounter when trying to serialize a diagram and, finally, explain the (non-standard) serialization system of GraphSquare.

Read more

GraphSquare architecture III

17 Jun, 2008  2 Comments  Diagramming, GraphSquare

In the previous part we looked at the MVC core, this time we’ll highlight the ideas and the code related to ‘tools’. A tool is basically a series of actions the user performs and which results in a command on the undo-stack. For example:

and so on. The abstract tool concept originates from the fact that if you don’t package a series of actions in a separate class you inevitably have a complex logical flow in the overriden mouse-methods of the surface. So, instead of having various if-then-else statements in the MouseDown, MouseMove and MouseUp handlers you simply loop over all registered tools and whichever tool is ‘on’ can react accordingly. This approach has the additional advantage that you can

Below is a snippet of the mouse handlers which are called by the surface corresponding to the mouse events on this surface. Note that the loop in these handlers are broken as soon as one of the tools have opted to handle the event. 

public void MouseDown(MouseEventArgs e)
{
 
 
    foreach (ITool tool in toolList)
    {
        if (tool is Core.IMouseListener)
            if ((tool as Core.IMouseListener).MouseDown(e))
                return;
    }
 
}
public void MouseMove(MouseEventArgs e)
{
    foreach (ITool tool in toolList)
    {
        if (tool is Core.IMouseListener)
            if ((tool as Core.IMouseListener).MouseMove(e))
                return;
    }
 
}
public void MouseUp(MouseEventArgs e)
{
    foreach (ITool tool in toolList)
    {
        if (tool is Core.IMouseListener)
            if ((tool as Core.IMouseListener).MouseUp(e))
                return;
    }
 
}

Most of the tools have some kind of visual feedback, on creating a rectangle you would see for example a rubberband which previews the end-result. For this purpose a few classes are necessray which specializes the ITool interface (depicted above) and all tools which need a rubberband are inheriting from it. The whole rubberband (sometimes called ‘marching ants’) affair is also taken separately in other constructs (a static helper class) and the process of creating tools becomes in the end a game of putting some blocks together. In fact, a dummy tool with visual feedback would look something like this:

public class DummyTool : RubberCreationToolBase
{
 
 
    #region Constructor
    ///<summary>
    ///Default constructor
    ///</summary>
    public DummyTool():base("Dummy Tool")
    {
 
    }
    #endregion
    public override void OnExecute(object sender, System.Windows.Input.ExecutedRoutedEventArgs e)
    {
        GhostManager.Surface = sender as DiagramSurface;
        base.OnExecute(sender, e);
    }
 
    public override void DrawGhost(System.Windows.Rect rec)
    {
        GhostManager.DrawRectangularGhost(rec);
    }
 
    public override void OnRubberCreated(System.Windows.Rect rec)
    {
        Surface.Controller.Output("The '" +this.Name + "' tool finished but no realshape was added.");
    }
}

The overridable DrawGhost method allows you to give whatever feedback you wish while the overridable OnRubberCreated allows you to do whatever you wish after the rubber was creates, i.e. after the user released the mouse. It’s precisely in this method that one should package the action (say, the creation of a shape) in a command and push it onto the undo-stack. In the dummy tool above only an informative message is displayed.

Of course, in order to manage the available tools and to connect them to the UI you need some more code in the form of some tool manager. The tool manager is just a wrapped generic list created through Unity inside the surface class. Note, in this context, that the concept of a tool only makes sense on the UI level and is, hence, not re-usable in other surfaces (e.g. a web-interface).

In the next part we’ll discuss the other end of the architecture; data abstraction and the serialization of diagrams.

keep looking »