GEF Project
Initial 3.1 Plan (Final)

Last revised Friday, July 08, 2005

 

Release Deliverables

  • Source code release for Graphical Editing Framework, available as versions tagged "R3_1" in the Eclipse Tools Project CVS repository.

  • Graphical Editing Framework SDK (includes runtime binary, source code, and ISV documentation) (downloadable).

  • Graphical Editing Framework runtime binary (downloadable).
  • Graphical Editing Framework Examples and source (downloadable).

Release Milestones

Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:

  • Friday Aug. 13, 2004 - Milestone 1 (3.1 M1) - stable build
  • Friday Sep. 24, 2004 - Milestone 2 (3.1 M2) - stable build
  • Friday Nov. 5, 2004 - Milestone 3 (3.1 M3) - stable build
  • Friday Dec. 17, 2004 - Milestone 4 (3.1 M4) - stable build
  • Friday Feb. 18, 2005  - Milestone 5 (3.1 M5) - stable build
  • Friday Apr. 1, 2005 - Milestone 6 (3.1 M6) - stable build

Target Operating Environments

GEF 3.1 will support all operating environments supported by the Eclipse Platform itself.  For a list of supported environments, refer to the Platform 3.1 plan.

Compatibility of Release 3.1 with 3.0

GEF 3.1 will be upwards compatible with GEF 3.0 to the greatest extent possible. We anticipate a small number of areas where maintaining compatibility would not be in the best interests of GEF or its clients. All such exceptions will be noted in the 3.1 release notes so that clients can assess the impact of these changes on their plug-ins and products.

API Contract Compatibility: GEF 3.1 will be upwards contract-compatible with GEF 3.0 unless noted. This means that programs in full compliance with contracts specified in 3.0 APIs will automatically be in full compliance with 3.1 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: GEF 3.1 will be upwards binary-compatible with GEF 3.0 unless noted. This means that plug-ins built for GEF 3.0 will continue to work correctly in 3.1 without change. Plug-ins with hard-coded references in their plug-in manifest file to the 3.0 version of GEF plug-ins will work in 3.1 provided the version match rule is "greaterOrEqual" or "compatible" (the default); references using "perfect" or "equivalent" match rules will be broken. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: GEF 3.1 will be upwards source-compatible with GEF 3.0 to the greatest extend possible. This means that source files written to use 3.0 APIs can often be successfully compiled and run against GEF 3.1 APIs. Since source incompatibilities are easy to deal with, maintaining source compatibility is considered much less important than maintaining contract and binary compatibility.  The addition of a single method anywhere could be an incompatible source change.  For this reason, source-incompatibilities will not be noted.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified as API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

3.1 Features

Committed Items

ShortestPathConnectionRouter. A draw2d connection router which will take advantage of the shortest path routing algorithm introduced in 3.0.  Such a router requires layout notification from a container figure defining the obstacles which are being avoided by the router.  The router should also support an optional list of user BendPoints. [draw2d]

Constrained horizontal ordering for nodes in a DG.  Ability constraint the left-to-right ordering of nodes in a directed graph.  If a node has a non-negative constraint, then its LTOR order in a given row will be constrained among other nodes with non-negative constraints.  This can be used to guarantee the order of subgraphs or nodes when it has meaning, for example when visually representing a switch statement or exception handling. [draw2d]

Performance improvements for ConnectionRouter.  Connection routers re-route whenever a connection anchor indicates that this is necessary.  Currently this occurs too often.  We will introduce a new notification for coordinate system changes which will reduce the frequency of connection re-routing. [draw2d]

EMF based GEF example.  An example which uses an EMF model.  The example will be an editor for ecore itself, allowing the user to diagram ecore classes and packages visually.  The model will be split between business and view data.

Better and faster horizontal coordinate assignment in DG.  Assigning horizontal coordinates to nodes in a directed graph layout is computationally expensive.  There is a linear algorithm for directed graphs which produces results of similar quality.  The algorithm could probably be extended to compound directed graphs.

Support for mirroring. All aspects of GEF work properly when displayed in a mirrored (RTL) workbench.

WYSIWYG Text Editing.  Improved performance and memory requirements for the draw2d text package.  Better line breaking behavior. Support for BiDi text spanning across multiple text figures. Support for selection rendering and caret calculations.  New example which prototypes textual editing.

Advanced graphics support. Expose new advanced graphics functionality in SWT in a way consistent with existing graphics features.