GEF Project
Initial 3.2 Plan (DRAFT)

Last revised Friday, July 08, 2005

 

Release Deliverables

  • Source code release for Graphical Editing Framework, available as versions tagged "R3_2" 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. xx, 2005 - Milestone 1 (3.2 M1) - stable build

Target Operating Environments

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

Compatibility of Release 3.2 with 3.1

GEF 3.2 will be upwards compatible with GEF 3.1 to the greatest extent possible. Any exceptions will be noted in the 3.2 release notes so that clients can assess the impact of these changes on their plug-ins and products.

API Contract Compatibility: GEF 3.2 will be upwards contract-compatible with GEF 3.1 unless noted. This means that programs in full compliance with contracts specified in 3.1 APIs will automatically be in full compliance with 3.2 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.2 will be upwards binary-compatible with GEF 3.1 unless noted. This means that plug-ins built for GEF 3.1 will continue to work correctly in 3.2 without change. Plug-ins with hard-coded references in their plug-in manifest file to the 3.1 version of GEF plug-ins will work in 3.2 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.2 will be upwards source-compatible with GEF 3.1 to the greatest extent possible. This means that source files written to use 3.1 APIs can often be successfully compiled and run against GEF 3.2 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.

Proposed 3.2 Features

Proposed Items

WYSIWYG Text Editing.  Textual document editing for GEF.  Keyboard input, navigation, and mouse selection support via new tools and viewer infrastructure.

Palette Keybindings. The user should be able to activate frequently used tools via a customizable keybinding.  There are limitation in the keybinding service which must be overcome to implement this feature, especially when the palette is in a view.  It must  be possible to define Keybindings programmatically for unknown extensions.  It should be possible to set the keybinding without necessarily using the keybinding preference page. [GEF, UI]

Palette UI improvements. New types of grouping controls for the palette, and possibly a refreshed look-and-feel.

Status bar support. Request objects will support the setting of an IStatus. Tools may display messages in the status bar.

OperationHistory bridge. Create a CommandStack implementation which delegates to the workbench's operation history.

Org-Chart layout algorithm.  Laying out a strict hierarchy of nodes in a tree layout similar to an org chart.  Two modes of layout are already demonstrated in the draw2d.examples project.  But, the algorithm needs to run in standalone mode, and flexible figures should be available which use the standalone algorithm. [draw2d]

Snapping Bendpoints.  Bendpoints should snap-to-grid when the grid is displayed.  They should also snap to guides if possible. [GEF]

Orthogonal Connection Router and Handles.  A connection router which routes connections using only horizontal and vertical line segments.  The user should be able to grab a segment and move it, which updates the constraint used for the connection. [GEF, draw2d]

Better keyboard traversal order for connection EditParts.  When selecting connections via the keyboard using forward-slash, the order is based on the model order.  The model order is often not important and does not correspond to the visual arrangement of the connections.  A better order could be used which is based on visual layout. [GEF]

New Layout Managers.  Layout managers for draw2d such as a "desktop" XY Layout, and a Grid or Table layout similar to SWT's GridLayout.  A desktop layout will anchor figures by their top-center location instead of top-left.  That way, their width can change without affecting the location of a centered icon.

Print Dialog. a dialog for setting print options such as page margin and fit-to-page settings.

Marker Display. Investigate the display of markers in a graphical viewer.

Unknown.  Please submit additional requirements to the mailing list.