Skip to main content
Jump to: navigation, search

Graphical Modeling Framework/Tutorial/Part 1

< Graphical Modeling Framework‎ | Tutorial
Revision as of 10:54, 1 February 2006 by Rgronback (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This tutorial will introduce the Graphical Modeling Framework (GMF), an Eclipse Technology subproject which aims to provide a generative bridge between the Eclipse Modeling Framework (EMF) and Graphical Editing Framework (GEF). In this tutorial, a mindmap application will be developed, as described here. This tutorial describes the functionality provided by GMF in its current state, using this build (1.0M4). It is expected that this tutorial will evolve with GMF to introduce new functionality as it is developed.

Overview of GMF

The use of both EMF and GEF for building Eclipse-based functionality is quite common. Many references below provide information on how to utilize these frameworks together, some of which inspired the GMF project itself. Before diving into a new GMF project, let's explore a little of how GMF approaches the task of utilizing EMF and GEF in a generative manner. Another article focusing on the runtime portion of GMF is found here.

The GMF project has adopted the term 'toolsmith' to refer to developers that use GMF to build plug-ins, while 'user' is typically refered to those who utilize said plug-ins, and who may also be developers. From a usability perspective, the number and types of 'models' utilized by GMF internally should be obfuscated to the greatest extent possible. However, it is likely that most toolsmiths are interested in knowing what is going on under the covers, so a description of each model is presented in this tutorial.

Below is a diagram that illustrates the main components and models used during GMF-based development. Core to GMF is the concept of a graphical definition model. This model contains information related to the graphical elements that will appear in a GEF-based runtime, but have no direct connection to the domain models for which they will provide representation and editing. An optional tooling definition model is used to design the palette and other periphery (overview, zoom, etc.), while read-only surfaces would not require no such a model.


Back to the top