Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
GEF/New and Noteworthy/3.10.1
- New and Noteworthy in 3.0
- New and Noteworthy in 3.5
- New and Noteworthy in 3.6
- New and Noteworthy in 3.7
- New and Noteworthy in 3.8
- New and Noteworthy in 3.9
- New and Noteworthy in 3.10
General
The GEF 3.10.1 (Mars SR1) release provides service releases for the production components Draw2d 3.x (3.10.1), GEF (MVC) 3.x (3.10.1), and Zest 1.x (1.6.1), as well as for the new GEF4 components (0.2.0). Please note that while GEF 3.10.1 (Mars SR1) is a bugfix release, some minor adjustments have been applied to the provisional API of GEF4. These are highlighted below as [INCOMPATIBLE CHANGE].
GEF4 Geometry 0.2.0
Aligned background color within the examples and added window titles where missing (M1)
GEF4 Layout 0.2.0
Fixed a bug where dynamic layout was not applied although it should (M1)
GEF4 FX 0.2.0
[INCOMPATIBLE CHANGE] FXMouseDragGesture, FXPinchSpreadGesture, and FXRotateGesture were renamed (M1)
The FXMouseDragGesture
, FXPinchSpreadGesture
, and FXRotateGesture
abstract base implementations located in package org.eclipse.gef4.fx.gestures
were renamed to consistently use the 'Abstract' prefix:
-
org.eclipse.gef4.fx.gestures.FXMouseDragGesture
was renamed toorg.eclipse.gef4.fx.gestures.AbstractFXMouseDragGesture
-
org.eclipse.gef4.fx.gestures.FXPinchSpreadGesture
was renamed toorg.eclipse.gef4.fx.gestures.AbstractFXPinchSpreadDragGesture
-
org.eclipse.gef4.fx.gestures.FXRotateGesture
was renamed toorg.eclipse.gef4.fx.gestures.AbstractFXRotateGesture
GEF4 MVC 0.2.0
[INCOMPATIBLE CHANGE] DefaultSelectionProvider was moved (M1)
org.eclipse.gef4.mvc.fx.ui.DefaultSelectionProvider
was moved to org.eclipse.gef4.mvc.ui.DefaultSelectionProvider
because it is independent of JavaFX.
[INCOMPATIBLE CHANGE] Refactored FXView and FXEditor (M2)
Removed getContents()
callback from FXView and FXEditor, so that population of viewers is now completely left to subclasses. Modularized createPartControl()
and dispose
methods so clients can easily overwrite and adopt individual aspects. In detail, introduced hookViewers()
, unhookViewers()
, activate()
, and deactivate()
hook methods.
FXViewer was responsible of creating a JavaFX scene and was provided with an ISceneContainer implementation, to hook the scene into a Stage (standalone) or FXCanvas (Eclipse UI integration) as follows:
// standalone viewer.setSceneContainer(new FXStageSceneContainer(primaryStage)); // Eclipse UI integration viewer.setSceneContainer(new FXCanvasSceneContainer(canvas));
The FXViewer had full control over the scene creation, so other root visuals than those provided by the viewer could not be set for the scene. This responsibility was moved out of FXViewer, so its visuals are now hooked into the scene as follows:
// standalone primaryStage.setScene(new Scene(viewer.getScrollPane())); // Eclipse UI integration canvas.setScene(new Scene(viewer.getScrollPane()));
Thereby, several FXViewers can now share a single scene, which is e.g. necessary to create a palette viewer. By means of an JavaFX SplitPane, this could look like follows:
// embed two viewers into a single scene by means of a SplitPane SplitPane sp = new SplitPane(); sp.getItems().addAll(viewer1.getScrollPane(), viewer2.getScrollPane()); sp.setDividerPositions(0.5f); primaryStage.setScene(new Scene(sp));
The now obsolete org.eclipse.gef4.mvc.fx.viewer.ISceneContainer
abstraction and the related org.eclipse.gef4.mvc.fx.FXStageSceneContainer
, and org.eclipse.gef4.mvc.fx.ui.FXCanvasSceneContainer
implementations were removed.
Enabled that multiple viewers can easily be used with an FXView or FXEditor (M2)
Factored out hookViewers()
and populateViewers()
hook methods from createPartControl()
, with a default implementation that is based on a single default viewer, which can easily be overwritten by subclasses to hook/populate multiple viewers.
Fixed a bug where the undo history was incorrectly cleared (M1)
Enhanced the default resize mechanism for better customizability (M1)
You can now define the visual that is resized (only the part's "main" visual was allowed before), and also define the initial size (the visual's layout-bounds were used before).