Graphical Modeling Framework/Versions/GMF 2.1
Graphical Modeling Framework 2.1 New and Noteworthy items
See GMF Project Plan for more details
Back to Graphical Modeling Framework
- 1 Previous Release N&N Pages
- 2 2.1 M1
- 3 2.1 M3
- 4 2.1 M4
- 5 2.1 M5
- 6 2.1 M6
Previous Release N&N Pages
GMF 2.0 New and Noteworthy - Released: June 28, 2007
GMF 1.0 New and Noteworthy - Released: June 30, 2006
Export Big Diagrams to Images
Huge diagrams that fail to be exported to a single JPEG, JPG, GIF, PNG or BMP image (Bug 160386), now can be exported to a number of images that combined together will display the image of the whole diagram (or selected editparts). An HTML file is created to view the whole image. The HTML file essentially contains a table, each cell of which is occupied by the appropriate piece of diagram's image (i.e. by the image file corresponding to that particular piece of the diagram). GMF's UI for exporting diagrams to images has been added a checkbox "Export to HTML", which will trigger exporting the diagram as described above.
The result of exporting a huge Geoshape diagram to HTML with the HTML file opened looks as follows:
Label Enhancements in the GMF Runtime
There were a number of usability bugs with the WrapLabel implementation and the TextDirectEditManager. The TextCompartmentEditPart and its helper classes also made assumptions that the figure of a TextCompartmentEditPart was a WrapLabel, making it difficult for clients to use any other label figures.
A new WrappingLabel has been created that uses GEF's Flow Figure classes to perform that text wrapping. The TextCompartmentEditPart and its helper classes have been modified so that there is only a dependency on a new interface, ILabelDelegate, which a client could use with any figure for displaying the label. The TextDirectEditManager has been changed to fix a few bugs and work with an ILabelDelegate.
Existing GMF Runtime clients need not make any code changes to enjoy the benefits of the new WrappingLabel as the existing WrapLabel subclasses the new WrappingLabel. However, it would be wise to test all behavior with text on diagrams to ensure there are no regressions.
A document which discusses the design, gives an overview of the changes made, and provides documentation for the clients on how to use the new WrappingLabel is attached to the bugzilla: Bug 162932
Group/Ungroup Functionality in the GMF Runtime
The GMF Runtime now has the ability to group and ungroup shapes. Check out the GMF Runtime Logic and Geoshapes Examples to see the new functionality. It's under the Format menu when multiple shapes are selected. The group/ungroup actions are not contributed by default by the GMF Runtime. To learn how to adopt the group/ungroup in a GMF diagram, see the document attached to Bug 111892. Note at this point, the group/ungroup functionality has not yet been adopted by the GMF Code Generator.
Additional Snap to Grid Functionality in the GMF Runtime
The GMF Runtime has extended the use of snap to grid for two existing components.
Arrange All / Arrange Selection
Edit parts selected will now snap to grid at the end of the arrange session, if the snap to grid property is enabled. Bugzilla 119252 Screen shots of "arrange all" in action with snap to grid on is shown below.
|Before Using Arrange All||After Using Arrange All|
Connection Bend Points
Connection bend points will now snap to grid when being dragged by the user, if the snap to grid property is enabled. Bugzilla 194282 A screen shot of bend points snapped to grid is shown below.
GEF Alignment Feature: Snap To Geometry added in the GMF Runtime
The GMF Runtime now has the capability to allow edit parts to snap to each other when editing. Bugzilla 188974 The snap to geometry property can be enabled and disabled in the ruler/grid property section. Snapping to other edit parts inside compartments are also supported. However, edit parts can only snap to other edit parts that share the same parent. (e.g: edit parts inside a compartment can only snap to each other) Some screen shots of this new feature are shown below.
Customize Palette Capability in the GMF Runtime
It is now possible for users to customize the palette in an application using the GMF Runtime. Users can: hide palette entries, rename palette entries, and set drawers to be open and/or pinned on startup. The customizations are saved in the workspace preferences.
At this point, saving the customizations does not work in GMF generated diagram editors because these editors do not have palette ids.
For further details see: Bugzilla 114117
Palette Enhancements in the GMF Runtime
- The palette can be resized, moved to the west side of the diagram, and minimized by the user; however, these settings were never persisted. Now these customizations are saved in the workspace preferences. See Bugzilla 117917
- There is a new method getInitialDockLocation() in DiagramEditorWithFlyOutPalette that allows the client to change the default docking location of the palette to be the west side. See Bugzilla 206371
Moving Shapes with the Keyboard
There have been complaints that it is too hard to move a shape with the keyboard. The current behavior requires the user to press the ‘.’ key which shows the move handle, then the arrow keys to move the shape, and then enter to accept the position.
The behavior has been changed in the GMF Runtime so that the user can now use the arrow keys to move a selected shape. The shape moves immediately when an arrow key is pressed. The Tab and Ctrl + Tab keys are now used to navigate between shapes on the diagram.
For further information regarding this work, see the feature design document attached to Bugzilla 111901.
For a complete listing of keyboard shortcuts in GMF, see the document titled "Developer Guide to Keyboard Accessibility" in the GMF documentation.
New Palette Look and Feel in the GMF Runtime
There have been many changes made in both GEF and GMF to add a new look and feel to the palette. The enhancement requests that addressed these are:
- New color treatment for drawers: Closed, expanded and hover.
- New color treatment for groups and tools: white background, mouse hover and selected (blue and yellow).
- New color treatment for stacks: white background, mouse hover and selected (blue and yellow).
- New Pin in and Pin out icons
- New Palette icon
- New dock and expanded look.
- Drawer icon is optional.
- Addition of a toolbar in the palette.
- New look for stack flyout.
- Stacks can be pinned open.
WYSIWYG .gmfgraph editor improvements
- Property pages for Styles, Layout and LayoutData are fully generated using new org.eclipse.gmf.formtk plug-in
- GridLayout is now supported by WYSISYG .gmfgraph editor
- Property page with possibility to modify Location, Preferred, Minimum and Maximum figure size was added
Generator model improvements
- Property to support tree routing style for links, now true by default
Dynamic (code-less) EMF models for domain
GMF Tooling used to require what seems to be regular EMF usecase - Java code for model implementation. However, there are scenarios when generating Java code is impractical (e.g. embedded domain, huge models (often completely derived from XSD), etc). With introduction of dynamic_package extension point in EMF 2.4, which makes it possible to distribute/publish models without generated implementation code easily, the need for GMF to support such model is undisputed.
There's new element in the GMFGen model, DynamicModelAccess (GenEditorGenerator#modelAccess), which, when added, forces GMF Tooling to produce a helper facility (with class/feature lookup methods, along with analogs for instanceof check and so on). Rest of the generated code uses the facility to check domain model condition, create new elements and so on.
By default, facility uses global package registry (and hence relies on domain model being registered with dynamic_package extension point). This can be easily changed in #getRegistry() method of the generated facility class (don't forget to mark it @generated NOT).
Inject Java Expression Body
The way expressions with language 'Java' being handled has changed. Prior to 2.1, body of the expression was used to generate placeholder implementation method. This seems quite odd when a method name is taken from body, and has been changed in 2.1. Now, method names are generated automatically, and (the fruitful part) there's a new boolean attribute in GenJavaExpressionProvider, which controls whether body of the Java expression should be injected into generated method. In most cases this allows toolsmith not to bother with @generated NOT for the Java expression methods, rather keeping their implementation in the model and having them injected on regeneration. Use GenJavaExpressionProvider#injectExpressionBody (defaults to false) to control injection for all expressions referenced by this provider.
Missing implementation for Java Expressions
To fill placeholder methods for Java Expressions, GMF Tooling used to generate code that throws a runtime exception. This behavior left as default, however there's new attribute, GenJavaExpressionProvider#throwException that allows Toolsmith to turn it off. When throwException is false, and injectExpressionBody (see previous N&N item) is also false, code generator places some compilable expression (appropriate for the context) instead of throws clause. For example, when Java expression used in metric, with expected Double return value, a Double.NaN return value would get generated.
Extensible GMFGraph and GMFGen models
It used to be a pain to augment GMF Tooling in a model-driven way. Say, one needed to add an extra figure class into graphical definition or custom attributes to utilize during editor codegeneration. With EMF child extenders enabled for GMFGraph and GMFGen models it's easy now to capture your custom extensions with an EMF model and still use default editors to edit GMF models.