Limaki 0.07 Release

Limaki is a framework for building interactive information visualization applications.

New features since Version 0.064:

* Generic GraphPair to transform one graph into an other and vice versa (bi-directinal)
* Persistent generic graph based on db4o's object database
* Labeling of Edges

Download at: http://downloads.sourceforge.net/limada/Limaki.007.zip

Architecture

The design of Limaki follows the principle of separation of concerns. Data and visual model are separated, similar to the model-view-controller design pattern. In a further step, the view part of the pattern is itself modeled after mvc-pattern to separate visual models from concrete displays. Modular view controllers are used to handle user input in a flexible and reusable fashion.

The Limaki.Graphs namespace provides generic Graph structures for data and visual models. A generic Edge interface represents the members of graphs. The Graph classes are implemented using ICollection and IDictionary instances to store the nodes and edges.

The Limaki.Data namespace provides generic Graph structures backed by Databases. Currently the only concrete Data.Graph implementation is based on db4o, but SQL (LinQ) based Data.Graph fill follow in a later version.

Widgets are providing access to visual attributes. An IWidget is a generic data structure which has a Shape, a Style and a generic Data property. An EdgeWidget is an instance representing an IEdge<Widget>.

A Scene wraps a WidgetGraph and a spatial index, providing fast access to the location of Widgets. A Scene has methods for hit-tests, iterations over Widgets contained in an area, and the overall bounds of the Widgets contained in the Graph. A Scene provides a Command-Queue as a central place to gather delayed operations on Widgets.

Specific visual appearance is provided by a Layout. A Layout sets the appropriate Style, determines the initial Shape, Size and Location of Widgets in a Scene. The Layout uses a Router to set the start- and endpoints of an EdgeWidget.

The actual appearance of Widget instances are determined by Renderers. A Renderer is responsible for drawing Widget.Data and Widget.Shape with the appropriate Style. For this task a Renderer uses Painters. Which Painter to use for a given Shape or Data is determined by a PainterFactory, which is asked for the appropriate Painter each time a Shape or Data is to be rendered.

A Layer is responsible to draw a Scene. It acts as a camera onto the contents of the Scene. The Layer draws all the widgets within its current view, and realizes panning and zooming.

An Action transforms a user interaction into a Command. With Actions moving, resizing, deleting, editing and so on are realized. Actions are bundled in an EventControler, which converts Windows.Forms.Events into Limaki specific Events.

The SceneControler is the mediator between Layout, Scene.CommandQueue and invalidation of the underlying Control. Its methods are called on initializing the Control and after each bundled execution of Actions by the EventControler. In this call it is responsible for executing all pending Commands in the queue, calculating the appropriate invalidation area of the Control, and calling the Invalidate-method of the Control.

The WidgetDisplay bundles all that separated classes and modules as a user control. It paints a Scene with a Layer, feeds the Camera with appropriate panning information, and calls the EventControler in case of user interaction.

A visual abstraction of a data-Graph can be made by creating a GraphPair. A GraphPair is a special data structure that includes the original data-Graph but also a visualization specific Graph. For any backing data-item or data-edge added to the GraphPair corresponding Widget instances are created, and vice versa.
Restrictions

This release is a proof of concept; the main purpose was to find out an architecture which provides a user-friendly graphical interface to manipulate graph structures.
This is a pre-alpha-release.

The software is tested on Net 2.0, Mono 2.0 under Windows XP

Known limitations of this release:

Editing works only on string-based widgets.
DragDrop works only on string-based widgets.
The graphical representation is limited to simple rectangles and lines.
There is no design-time support; you have to code everything “by hand”.
Mono:
Although I tried my best to provide the full feature set on mono, you have to consider the following limitations when using it under mono:
Speed: around 1/3 of speed under mono-windows, less on mono-linux
Cursor-Handling: the cursors don’t show up as in .NET if you manipulate nodes (resizing, moving)
No DragDrop-support