3765人阅读
&&& 早期的图形化界面应用程序主要使用GEF框架来开发，如：JBPM流程定义工具，采用GEF+javaBean的组合模式，这种方式不好的一点就是在模型层的处理上过于繁琐，需要开发人员人为实现模型通知机制，而且也不利于后期的扩展维护，一旦有新需求出现，修改模型结构非常困难。
&&& 于是有人尝试EMF+GEF的组合模式，因为EMF在模型映射处理上相对比较成熟，而且由EMF所驱动出的实体类本身也具备了通知机制，可以将模型结构的状态改变通知到控制层，但在使用的过程中也有新的难点出现，EMF和GEF分别有自己的命令处理机制来用于定义对模型的修改操作，两套机制所定义的接口不同，没有办法实现通用。
&&& GMF框架的设计解决了EMF和GEF整合的困难，通过适配的方式将两种命令机制关联起来，并且在整合两个框架的同时，也做了很多功能上的扩展，包括：
&&& 1、从Ecore元模型中扩展出Notation Model(修饰模型)用于定义节点的修饰(字体、坐标、布局约束等),从而将节点的修饰属性从业务模型中独立出来，让Ecore模型只关注在业务逻辑的建模处理上。
&&& 2、GEF框架的视图展现主要使用了Java的draw2D技术框架，需要开发人员手工编写相应的Figure类来定义视图节点的显示，GMF框架对视图的展现做了进一步的封装处理，将视图的定义抽象到模型配置文件中去进行管理，在由Runtime子框架去解析生成相应的Figure实体，从而让开发人员以定义模型的方式来定义视图。
&&& GMF框架是一种典型的模型驱动开发方法，开发人员甚至可以在不编码的情况下完成模型实体到上层应用的整个驱动过程，但是由它所驱动出的项目实例只是针对大众化需求的一个功能定制，如果想加入个性化需求，修改工程代码也是在所难免的。新建一个GMF项目，我们要走以下这样一个流程：
既然是模型驱动开发方法，肯定离不开模型的定义
&&& 首先借助EMF框架来完成Domain Model的建模处理 生成模型的配置文件 *.
&&& 然后定义视图模型，视图的展现主要包含两部分，分别是Figure节点和用于创建Figure的工具,两个模型分别保存到*gmfgraph文件和*.gmftool文件当中;
&&& 直到现在这三个模型在应用上还是处于相互独立的状态，需要有一个模型来将他们关联起来，以达到级联操作的效果，这个模型就是映射模型(Mapping Model);
&&& 有了映射模型，GMF的模型定义操作已经完成一大半，剩下的就是通过映射模型来生成Generator模型，而我们项目的代码最终是由Generator模型来驱动生成的。
&&& 在由映射模型得到Generator模型的过程中需要用到EMF的genmodel模型，我们都知道EMF是基于两种元模型来构建的，Ecore模型
主要定义了模型的基本结构，而genmodel模型主要配置了有关代码生成方面的相关信息，Generator模型同样需要genmodel模型属性配置来用于代码的生成。
接下来我们以实践的方式来演示整个操作流程
首先使用EMF框架进行业务领域建模，模型结构大致如下：
&&& 该模型的主要功能是效仿JBPM流程定义工具，并在功能上稍做扩展，使用过JBPM的人都知道，在JBPM自带的流程编辑器里，任务分配器的编写是不能以图形化界面的操作形式来展现的，需要开发人员手工修改对应的XML文件，而我们所要做的扩展功能就是可以让用户以拖拽的方式来为任务指定分配器。
&&& 目前已定义的分配器包括两种：
&&& PersonAssignment表示分配到人；
&&& PositionAssignment表示分配到岗位；
&&& 其他节点都是效仿JBPM常用标签进行定义的，Start表示开始节点，End表示结束，Task表示任务，Transition表示连接，因为只是实例的演示，所以没有把JBPM的标签全部迁移过来,只是定义了几种比较常用的。
&&& 另外需要注意一点的是，使用EMF进行建模处理一定可以对外提供一个根对象用来表示整个模型(比如这里的Process对象表示整个流程实体)，而其他对象一定可以通过组合的方式直接或间接添加到根对象之中，或者说实体类层级之间的引用关系一定要设计成组合模式，这样EMF框架才可将这些资源实体保存到同一个资源文件中去。
&&& 有了Ecore模型之后，可以基于该模型创建genmodel模型，正如前面强调的Ecore模型定义了模型的基本结构，而genmodel模型主要配置有关代码生成方面的相关信息,经常修改的几个属性包括：
&&& Base Package:表示EMF所生成的代码默认保存在以哪个路径为基础的包当中；
&&& Runtime Platform:模型所驱动出的项目实例以什么样的方式运行，IDE-以插件的形式运行；RCP-以Application形式独立运行。我们暂时把他设置成以插件的形式运行。
&&& 按照流程，业务模型建好之后，我们需要建立视图模型，首先建立graphic model，在向导界面中选择Graphicl Modeling Framework路径下的Simple Graphical Definition Model，在接下来的向导页中Diagram Element对象一定要选择Ecore模型所对外提供的根对象,这里也就是process对象
&&& 在接下来的选项页中，为了演示视图模型的定义操作，去除所有的选项，建立模型配置文件之后，我们会以手工的方式来定义这
些视图元件。
&&& 模型建立好之后，文件的层级结构是这样的，首先模型的根节点是Canvas对象，表示一个画布，其他视图节点都是绘制于该画布之上，然后Canvas节点包含了一个Figure Gallery子节点，该节点的功能主要用于声明Figure的描述信息。在这里我们新建一个Figure Descriptor子节点，将Name属性设置成TaskFigure，表示该Figure是用于描述Task视图的，然后为该节点添加一个Rounded Rectangle子节点,表示Task视图是一个圆角矩形，在属性视图里可以对它的属性信息做一些修改:
Corner:表示圆角的弧度，Fill表示是否填充，Line Kind表示轮廓类型，Line Width表示轮廓线的宽度，outline表示是否显示轮廓线，可根据需求自行调整。
接着为其添加一个Flow Layout子节点，来为该圆角矩形指定布局信息：
vertical表示是否是垂直方向布局,Force Single Line表示是否布局到一条线上,Match Minor Size表示是否匹配最小宽度或高度,难于理解的可能是Major和Minor两个词的含义，其实它们所代表的意识是和Vertical属性值有关的,拿Major Alignment来讲，如果Vertical属性为true则Major Alignment表示垂直方向对齐方式,相反，如果Vertical属性设置为false,则Major Alignment表示水平方向对齐方式。
&&& 除了有圆角矩形之外，我们还需要在矩形上绘制一个Label用来显示任务名称，实现方法是为Rounded Rectangle节点添加Label子节点，这样一个任务节点的视图就定义好了。
&&& 然而我们的模型定义并没有结束，就像刚开始提到的，Figure Gallery节点只是定义了视图组件的描述信息，所声明的这些组件并没有绘制到Canvas上去，换个角度说，Figure Gallery节点只是声明了一些组件类，这些类要想拿来使用还有一个实例化的过程。怎样将这些组件类实例化呢？
&&& 在Canvas节点下新建一个Node节点,Name属性设置成Task,Figure属性设置成我们刚刚定义的TaskFigure,这样就将一个TaskFigure的实例绘制到Canvas组件上了,同样，我们还需要把TaskLabelFigure也绘制到Canvas组件上,新建一个Diagram Label子节点，Figure属性同样选择TaskFigure,所不同的是我们还要为它指定Accessor属性,Accessor属性相当于一个方法，可以通过它来获取定义的组件,在TaskFigure下面新建一个Child
Access子节点，Figure属性选择TaskLabelFigure,然后将新建的Child Access赋予Accessor属性，这样一个简单的视图模型就创建完毕了。
按照流程，我们继续创建tool model
&&& 在Graphical Modeling Framwork路径下面选择Simple Tooling Definition Model，Diagram Element选项中，同样选择Ecore模型所对外提供的跟对象Process，向导结束，模型结构大致如下：
&&& Tool模型主要定义了创建Figure所需要的一些工具，这些工具由统一的调色板(也就是Palette节点)来进行管理，而其子节点Tool Group用于定义工具组，可以将具有相似功能的工具添加到同一个组中来进行管理，这里，我们新建一个工具(Creation Tool)用于绘制Task Figure，设置Title属性为&任务&，Description属性为&创建任务&，然后为该工具指定图标信息，分别添加Small Icon Default Image子节点和Large Icon Default
Image子节点，这样，一个简单的工具模型也创建好了。
&&& 接下来所需要做的任务就是将把3个在功能上相互独立的模型映射关联起来，创建映射模型。
&&& 在Graphical Modeling Framwork下面选择Guide Mapping Model Creation,然后依次选择已创建的3个模型，在向导页的最后一页，移除所有Links选项和Nodes选项(因为我们要以手工的方式来演示映射模型的配置过程)，点击Finish模型创建完毕。
&&& 接下来我们所需要做的工作是将Ecore模型的Task节点,gmfgraph模型的TakFigure和gmftool模型中的工具节点相互关联起来。首先在Mapping节点下面新建一个Top Node Reference子节点,将Containment Feature属性设置成Process.nodes，注：这里一定要是ContaimentFeature，因为Process和Node之间的关系是组合关系，而不是简单的对象引用关系；然后为其添加Node Mapping节点，将Element属性设置成Task，DIagram
Node属性设置成TaskFigure，Tool属性设置成&Creation Tool任务&，这样3个模型所定义的节点元素就相互关联起来了。
最后为Task节点添加name属性到TaskLabelFigure的映射,新建一个Feature Label Mapping子节点，设置Features to display属性为Node.name,Diagram Label属性为Diagram Label TaskName，点击保存，映射模型创建完毕。
最后一步，由映射模型生成generator模型
右键映射模型文件，选择create generator model,依次选择创建好的映射模型和genmodel模型，最终得到generator模型，有了该模型之后，我们便可基于模型来驱动出项目代码。
首先借助与EMF的genmodel模型来生成与模型相对应的实体类和适配器类，然后右键process.gemgen，选择generate diagram code,GMF便会生成我们整个编辑器的上层应用。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：353883次
积分：4271
积分：4271
排名：第5419名
原创：82篇
评论：101条
阅读：23538
(2)(3)(3)(1)(2)(1)(1)(1)(4)(6)(6)(4)(3)(4)(2)(1)(1)(8)(4)(5)(1)(7)(2)(1)(3)(3)(1)(2)---Navigation---Main PageCommunity portalCurrent eventsRecent changesRandom pageHelp
---Toolbox---Page informationPermanent linkPrintable versionSpecial pagesRelated changesWhat links here
Update Site
GMF Notation:
GMF Runtime:
GMF Tooling: ,
This tutorial will introduce the
(), an Eclipse Modeling Project project that aims to provide a generative bridge between the
In this tutorial, a
application will be developed, as described . This tutorial describes the functionality provided by GMF in version 2.0.1. It is expected that this tutorial will evolve with GMF to introduce new functionality as it is developed. New functionality will be covered by installments added to this tutorial, each with a corresponding viewlet. A viewlet for this installment of the tutorial can be found . The complete solution to this tutorial is maintained in
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 .
The GMF project has adopted the term 'toolsmith' to refer to developers that use GMF to build plug-ins, while 'practitioner' is used to referred 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 hidden 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 linked from the
GMF-Tooling workflow
This 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 (menus, toolbars, etc.).
It is expected that a graphical or tooling definition may work equally well for several domains. For example, the UML class diagram has many counterparts, all of which are strikingly similar in their basic appearance and structure. A goal of GMF is to allow the graphical definition to be reused for several domains. This is achieved by using a separate mapping model to link the graphical and tooling definitions to the selected domain model(s).
Once the appropriate mappings are defined, GMF provides a generator model to allow implementation details to be defined for the generation phase. The production of an editor plug-in based on the generator model will
that is, the diagram runtime (or "notation") model. The runtime will bridge the notation and domain model(s) when a user is working with a diagram, and also provides for the persistence and synchronization of both. An important aspect of this runtime is that it provides a services-based approach to EMF and GEF functionality and is able to be leveraged by non-generated applications.
With the basics of GMF covered, let's now walk through the process of using GMF in the development of a graphical editing surface for a particular domain. First, you will need to install GMF and its dependencies.
This version of the tutorial was written using this build of GMF 2.0.1.
However, it is advised to use GMF Runtime 1.5.x with GMF Tooling 2.4.0, respectively from the following update sites:
The TaiPan example referenced below is maintained in
and should remain functional with the latest builds of GMF, even if the tutorial is not quite up-to-date. If not, please open a bug.
If you're anxious to see GMF in action, check out the Taipan example projects into your workspace from CVS by switching to the CVS Repository Exploring perspective and adding a repository location as shown in the image to the right. Otherwise, you can skip to the next section.
Navigate to
and select the org.eclipse.gmf.examples.taipan.* modules. Right-click and select Check Out. If you are not using the latest build and prerequisites of GMF, you can always check out the version of the Taipan by date to correspond with the version you're using. The important point is that you'll need to work with synchronized versions of the GMF SDK and the Taipan example. To do this, after checkout you can right-click on the projects and selecting 'Team | Switch to Another Branch or Version...' and then choose 'Select the tag from the following list' and use the 'Add Date...' button at the bottom to enter the date of the GMF 2.0.1 release (28 September 2007). Press Finish and you're set.
Switch to the Plug-in Development perspective and open the models folder within the org.eclipse.gmf.examples.taipan project. Explore each of the models found hereand their element properties.
You'll notice that there are full and RCP versions of the generated Taipan examples to explore.
We will look at each of the models in turn during the tutorial, but just to validate your configuration, you should be able to run this sample in a runtime workspace (simply accept the defaults for a new 'Eclipse Application' run configuration). In the runtime workspace, create an empty project and a new 'TaiPan Diagram' found in the Examples folder of the New dialog. Name it whatever you wish and click Finish. The generated diagram editor should open for you to explore. Some things to note in particular are:
tool palette and overview
layout and selection tools
diagram image export (svg, bmp, jpeg, gif)
tabbed properties view
font and color options for selected element
link routing and style options
pop-up bars and connection handles
notes and geometric shapes
animated zoom and layout
diagram printing
Create a new launch configuration to run the TaiPanApplication and select just the Taipan *.rcp plug-in and its dependencies on the Plug-ins tab to run Taipan as a standalone RCP diagram editor.
This concludes the quick start portion of this tutorial. What follows next is a more detailed look at each of the models shown above during the creation of a mindmap modeling surface.
The screen recording in Eclipse Helios, Mac OSX is available at this URL:
Before we start, you should specify for your workspace (or at least for your GMF projects) 1.5 compiler settings.
In Window... Preferences... Java...Compiler options, make sure you have selected a Compliance Level of 1.5.
As described , one of the usage scenarios for GMF includes producing a graphical surface for a mindmap application, to eventually be complemented with an alternative view of its temporal information (likely a Gantt chart - feel free to contribute this to the wiki). This section of the tutorial will demonstrate GMF's capabilities toward this end, and will continue to evolve as the project matures. If you'd prefer to follow along using a set of projects representing the complete solution to this tutorial, you can find a set of mindmap projects in CVS under the
Note that if you choose to grab all mindmap projects, you'll need to install the Experimental SDK in order for all projects to compile.
GMF comes with a Tutorial Cheat Sheet found under 'Help | Cheat Sheets...' (Note that if you've installed GMF onto a platform without the SDK, i.e. using Europa's update manager, you will need to open the Cheat Sheets view from the Window | Show View... | Other... menu and then open the GMF Tutorial Cheat Sheet from the view menu).
If you open this cheat sheet and follow through each step, you can accomplish most of this first tutorial segment, while taking advantage of some actions that will launch and pre-populate wizards to get you started.
Try this now to create your new project.
Alternatively, you can begin by creating an "New GMF Project" found under 'Graphical Modeling Framework' in the New dialog (Ctrl+N). Name the project 'org.eclipse.gmf.examples.mindmap' and create a new folder named 'model' in its root.
Although it may seem necessary to begin with the domain model, it is not in the case with GMF, as the diagram definition is maintained separate from the domain. However, we will begin with the domain in the tutorial as it is likely familiar to most, and will allow us to jumpstart our diagram definition from the domain model using a wizard in the next section.
A basic domain model for our mindmap is found in an Ecore version . Following the cheat sheet, in the section "Domain Model", select the Model Importers ... Ecore Model ....
On the next panel, copy the URL from the download link found on the
and select the "Load" button.
(Alternatively, you may start with an XSD of the mindmap model, found
(you'll need to install the XSD feature from EMF in this case). Copy this file into your 'model' folder and feel free to examine the model, if you wish. GMF provides a (bootstrapped) graphical editor to complement the standard EMF generated editors, and is packaged in the SDK.
To render the mindmap.ecore (or any *.ecore model) with the editor, simply right-click the file and select 'Initialize ecore_diagram diagram file' from the menu.
Mindmap domain model
To continue, create a new mindmap.genmodel from the mindmap.ecore file using the New & Eclipse Modeling Framework & EMF Model wizard. You may wish to change the 'Base Package' property for the genmodel's 'Mindmap' package to org.eclipse.gmf.examples to have your generated packaging match the project name. These steps are also covered in the next step of the cheat sheet.
Generate the model and edit code using the right-click menu available from the root of the generator model. There is no need to create an editor or tests, but you are welcome to do so if you'd like. Now, we're ready to begin creating the graphical and mapping definitions for our mindmap application.
A graphical definition model is used to define the figures, nodes, links, etc. that you will display on your diagram. The model you will work with to do this is seen at the right.
Continuing on with the next step in the cheat sheet, we will create a new graphical definition model. The cheat sheet will launch the Simple Graphical Definition Model wizard, which is found in the Graphical Modeling Framework folder of the New (Ctrl + N) dialog. Select the 'model' folder under your org.eclipse.gmf.examples.mindmap project for the mindmap.gmfgraph model, and on the next page of the wizard use 'Browse' to locate your mindmap.ecore file.
Select our Map class as the Diagram element.
On the last page of the wizard, select a minimal set of element, link, and label options for our Topic class as shown in the image. Later on, feel free to experiment with this wizard and observe its output.
For now, we're just interested in getting a minimal set of models to get started. Click 'Finish' to complete.
If you examine the model, you will find a Canvas at the root with a Figure gallery containing basic Rectangle, Label, and Polyline Connection elements. These are used by corresponding Node, Diagram Label, and Connection
elements to represent our Topics from the domain model. We can leave the defaults as-is for now and continue with our tooling definition in the next step of the cheat sheet.
Tip : There are several figure galleries intended for reuse and included with GMF. You can load these into your *.gmfgraph model (or *.gmfmap model) by using "Load Resource..." and entering platform:/plugin/org.eclipse.gmf.graphdef/models/basic.gmfgraph for the Resource URI. Others available include classDiagram.gmfgraph and stateDiagram.gmfgraph.
As mentioned above, the tooling definition model is used to specify the palette, creation tools, actions, etc. for your graphical elements. To the right is a diagram of the model.
The cheat sheet will guide you through a very similar process for getting started with our Simple Tooling Definition Model. In fact, the two steps are virtually identical, as the mindmap domain model is loaded and examined for possible tooling needs. We will simply select the same options we did for the graphical definition, save a tool for the Topic name label, and begin with a very simple palette for our Topic elements.
Looking at the model provided for us, we see there is a top-level 'Tool Registry' element, under which we find a Palette. The palette contains a Tool Group with Creation Tool elements for both Topic nodes and links for subtopic elements that were identified by the wizard. We will reorganize these and modify them a bit in the future, but for now we'll leave the defaults and move on to the mapping definition. Feel free to browse this model and inspect its properties to familiarize yourself with tooling definitions.
The mapping definition model will let us bind the three models we have so far: the domain, the graphical definition, and the tooling definition.
To the right is an image of this model. This is a key model to GMF development and will be used as input to a transformation step which will produce our final model, the generation model.
Continuing on with our cheat sheet, follow the instructions to launch the Guide Mapping Model Creation wizard. We will again select the 'model' folder to hold our mindmap.gmfmap file and move on to load each of the preselected mindmap.ecore, mindmap.gmfgraph, and mindmap.gmftool models. On the next page, select 'Map' as the Diagram Root Element, accept the mindmapPalette from the selected tooling model, and then accept the selected mindmap diagram canvas.
Finally, make the last page look like the image below.
Note that you can adjust the properties for the selected node or link by using the 'Change...' button in the dialog.
One thing we need to do manually is create a Label Mapping for our TopicNameLabel from the graphical definition. The result should look like the image to the right.
While in the properties view, check the mapping of the TopicNode Node Mapping as well, to make sure it has the desired values.
Because of , carefully check that the mapping wizard assigned the proper tool to both the Topic node and the Subtopics link: click on the Topic and Subtopic node mappings, and ensure that the "Tool" in the properties is the one you created for Topics in your .gmftool.
Before moving on, let's pause to describe the mappings. We'll start with the Label Mapping, as it's the one we're looking at here. It's a straightforward mapping, with the Diagram Label property set as we discussed and a mapping to the 'EAttribute name' feature on our Topic element in the domain model.
Moving up to the Node Mapping, we see that our Diagram Node is mapped to the TopicNode of our graphical definition with its corresponding domain model element mapped to our Topic class. The Topic creation tool is also specified in the mapping.
Above the Node Mapping you will find a Top Node Reference. Its Containment Feature is set to the 'EReference rootTopics' feature of our Map class. So, when new Topic nodes are added to the diagram, the instance of our domain Topic will be added to the rootTopics containment reference of our Map class. The label of the node will display the 'name' attribute of the Topic.
The Map class itself is represented by the Canvas. Select the Canvas Mapping element to see this defined, along with the map to the Palette in our tooling definition. Finally, if you select the Link Mapping, you will observe that connections represented by our TopicSubtopicsLink are mapped to the 'EReference subtopics' feature of our Topic class, and are created with our TopicSubtopics Creation Tool.
Tip : It is important to select the proper element when defining ma that is, before GMF does more complete filtering and validation. A good way to ensure you have selected the element you intended (as several may have the same name), open the mapping definition (*.gmfmap) file in a text editor, when in doubt.
The last model to cover in this tutorial, and the one that is not as critical to understand at this point, is the GMF generator model. See the diagram to the right if you're interested in examining this model.
Now that the minimal graphical elements and mappings are defined, we can generate the code needed to test our work so far. To accomplish this, we will first create a generator model (*.gmfgen) in order to set the properties for code generation, similar to the familiar EMF genmodel. To accomplish this, right-click the mapping file and select 'Create generator model...' as shown below. When prompted, keep the default name 'mindmap.gmfgen'.
Now, we can examine the generator model to see what it includes (if you're the curious type). We'll keep all the default values for now and right-click the mindmap.gmfgen file and select 'Generate diagram code' to proceed. If all goes well, you will see a "Code generation completed successfully." message dialog. Dismiss the dialog, opting to never see it again, and notice the new org.eclipse.gmf.examples.mindmap.diagram plug-in in your workspace.
Up to this point, the models used have been fairly straightforward to edit and understand.
The transformation that takes place to create the generator model (*.gmfgen) from the mapping model involves a bit of logic that is important to understand.
However, it is not required to understand the details at this point in the tutorial, so additional information can be found
for those interested.
Notation Model, view in
Recall that the runtime uses its own 'notation model' to display and persist the graphical components for your diagram. An image of this model is linked here for those interested.
Now that we have generated the plug-in needed for our diagram, let's launch a new runtime workspace and test the diagram. The default settings of a new Eclipse Application runtime configuration should work fine, while you may opt to run a minimal configuration that includes only your generated plug-ins and their runtime dependencies within an org.eclipse.platform.ide configuration.
Create an empty project and invoke the New... dialog (Ctrl+N). Under 'Examples' you'll notice your new Mindmap Diagram. Create a new diagram and explore its functionality, and look for the creation of the domain model instance as you add and save diagram elements. Of course, we've only specified enough in our diagram definition to allow for simple Topic elements and subtopic links.
Tip : If you'd like remove the icons from your labels (as shown here), try setting the 'Element Icon' property on your 'Diagram Label TopicNameLabel' element in your mindmap.gmfgraph model to 'false'.
They are enabled by default.
As you have seen, using GMF as a means by which to get started creating graphical editors for your domain models is fairly straightforward. We have seen how creating a graphical definition and a mapping definition to the chosen domain can be used to generate much of the basic functionality expected in an EMF/GEF-based editor. In the future, GMF will mature and include more advance capabilities, so check back to see how this tutorial matures along with the project. In the meantime, if you've skipped over links that provide more detail on certain aspects of GMF, now may be the time to do so. Otherwise, feel free to continue with the .
GMF Tutorial Part 1 - Get Started with GMF
, IBM Redbook
, Eclipse Corner Article