Skip to main content

Graphiti

Graphiti

The Graphiti project is a proposed open source project under the proposed GMP container project within the Eclipse Modeling Project (EMP) Top-Level Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the Eclipse Modeling forum.

Background

Eclipse provides a modeling infrastructure evolving around the Eclipse Modeling Framework (EMF). Offering graphical representations and editing possibilities is an essential part of EMF. SAP has built and plans to contribute an Eclipse-based graphics framework to enable easy development of state-of-the-art diagram editors for domain models. SAP plans to contribute the developed framework under the name Graphiti.

The proposal of this new project needs to be aligned with introducing a new umbrella project hosting the graphical modeling framework GMF and Graphiti as proposed in the Bugzilla bug report 304589. The name of this new umbrella project will be GMP; it will host Graphiti and three subproject split from GMF (Tooling, Runtime and Notational, see bug report for details).

Scope

The objectives of the Graphiti project are the following:
  • Provide an easy to use and well structured plain Java API for building graphical tools
  • Provide documentation and tutorials for doing so
  • Limit the dependencies of the framework to an absolute minimum to support RCP-like scenarios
  • Provide optional components beyond the RCP use case to ease e.g. IDE integration
  • Provide the ability to use any existing layout algorithms for auto layouting a diagram

As the Graphical Modeling Framework (GMF) already exists as a project targeting a similar objective, we distinguish Graphiti from GMF as follows:

  Graphiti GMF
Architectural Concept runtime centric API generative
API self-contained refers to GEF functionality
Client Logic centralised (feature concept) functionality distributed since there are no constraints
Look&Feel sophisticated default Look&Feel defined by usability specialists (highly customisable according to the tool requirements) simple default Look&Feel (highly customisable according to the tool requirements in generated coding)

Description

The Graphiti framework utilises Eclipse's GEF and Draw2D for diagramming and supports EMF on the domain side. The diagrams are described by a platform independent metamodel and the diagram data is kept strictly separate from the domain data. This enables rendering an existing diagram in various environments (besides Eclipse this could be e.g. within a browser) even without having access to the underlying domain data. This also enables displaying a diagram within other environments (e.g. using flash inside a browser) simply by providing a new rendering engine for the environment that can interpret the Graphiti diagram. (Currently only a rendering engine for Eclipse GEF exists.)

Graphiti is strictly API-centric: a user of the framework writes plain Java coding and (besides Graphiti) only needs to know EMF to use the framework and to build an editor -- no knowledge of Draw2D or GEF (or any other used rendering framework) is required.

Editors built with the framework are equipped with a standardised Look&Feel (designed together with usability experts) which leads to a more coherent UI in Eclipse-based tools; nevertheless tools can easily define a somewhat different Look&Feel according to their special needs by simply overriding and changing the default behaviour of the framework. Rapid prototyping is supported by simple APIs and base classes which can be used to refine an editor in an evolutionary way. The user of the framework writes so-called features to add functionality to the editor. For instance, one would write features for creating new model objects and their graphical representation (Create Features), or for creating a graphical representation for an already existing model object (Add Features). The complete life cycle (creating, editing, renaming, moving, deleting...) of model objects and their graphical representations can be defined and controlled by implementing such features. The standard behaviour for the different operations is covered by so-called default features, if the user of the framework does not declare any special behaviour. Step by step, these default features can be replaced or extended with further functionality. Additionally, the framework comes with a hook for so-called custom features to implement non-standard behaviour and further operations inside the tool.

Architecture

The following diagram visualises the framework as perceived by a tool developer.

Architecture of Graphiti

The Interaction Component is provided by Graphiti, whereas the Diagram Type Agent (DTA) is implemented by the user of the framework and defines the new diagram type that is contributed by the tool. It provides one or more Tool Behaviour Providers that define how the tool behaves in specific situations; the tool can influence, e.g., what will be displayed in the palette of the editor, how selection and double clicking is handled, that some special rendering is necessary for certain objects, how zooming is handled and so on. It is also the responsibility of the Tool Behaviour Provider to define which context menu and context buttons are available in a certain scenario. The context buttons appear around the currently hovered shape and can be used by the user in a very convenient way to trigger object specific operations; they are completely rendered by Graphiti. The tool only provides the operation, a name, and potentially an icon for it. Of course, operations can also be triggered via context menu entries.

Context Buttons

These operations are defined by the tool by implementing features or by using the default features provided by the framework. Besides, there is a so called Feature Provider for a diagram type which is responsible to define the features that are available and are to be used in the tool in a specific scenario.

Relationship with other Eclipse Projects

  • Graphiti uses EMF on the domain side.
  • Graphiti uses Draw2D and GEF for diagramming.
  • Graphiti complements the offering of GMF which follows a generative approach while Graphiti follows a runtime-oriented and API based approach.
Besides that proposed Eclipse project WTP/JPA Diagram Editor already uses Graphiti as its underlying graphical framework.

Initial Contribution

The initial code contribution will come from SAP where Graphiti was developed originally as part of their MOF based modeling infrastructure. Later Graphiti was ported to EMF; this version will be the basis for the coding contributed to Eclipse.

Legal Issues

There are no known legal issue with Graphiti.

Committers

The following individuals are proposed as initial committers to the project:

  • Michael Wenz, SAP, lead
  • Christian Brand, SAP
  • Matthias Gorning, SAP
  • Tim Kaiser, SAP
  • Jürgen Pasch, SAP

Mentors

The following Architecture Council members will mentor this project:

  • Cedric Brun, Obeo
  • Bernd Kolb, SAP

Interested Parties

The following individuals, organisations, companies and projects have expressed interest in this project:


The need for a runtime-centric graphical framework enabling easy development of graphical editors in EMP was discussed at the Eclipse Summit Europe 2009 with the above-mentioned parties.

Project Scheduling

We will be present with Graphiti at EclipseCon 2010 to raise the community awareness of the project. There will be a talk on Graphiti and we will have a poster at the poster reception . We plan the initial code contribution for end of March 2010 and hope to have an incubator release by June 2010, aligned with the Helios release. Also after the initial code contribution we plan to open the project for further contributors from other interested parties.

Changes to this Document

December 15, 2009 Document created
March 18, 2010 Document updated

Back to the top