Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "GEF/GEF4/MVC"

< GEF‎ | GEF4
m (IPolicy, AbstractPolicy)
m (IPolicy, AbstractPolicy)
Line 289: Line 289:
 
An <code>IPolicy</code> is similar to an [[#IBehavior, AbstractBehavior|IBehavior]] in that it is bound to an [[#IVisualPart, AbstractVisualPart|IVisualPart]]. However, behaviors start actions by themselves (they are active), while policies are always called from the outside (they are passive).
 
An <code>IPolicy</code> is similar to an [[#IBehavior, AbstractBehavior|IBehavior]] in that it is bound to an [[#IVisualPart, AbstractVisualPart|IVisualPart]]. However, behaviors start actions by themselves (they are active), while policies are always called from the outside (they are passive).
  
There are basically two kinds of policies, interaction and transaction policies. An interaction policy is called by a [[#ITool, AbstractTool|ITool]] to handle part of an interaction (e.g. click, drag). A transaction policy is one that may be used by other (interaction or transaction) policies to actually perform an operation (e.g. create model element). It should implement the [[#ITransactional|ITransactional]] interface and encapsulate the operation into an IUndoableOperation.
+
There are basically two kinds of policies, interaction and transaction policies. An interaction policy is called by a [[#ITool, AbstractTool|ITool]] to handle part of an interaction (e.g. click, drag). A transaction policy is one that may be used by other (interaction or transaction) policies to actually perform a visual or semantic operation (e.g. create model element). It has to implement the [[#ITransactional|ITransactional]] interface , encapsulating the to be performed operation as an [http://help.eclipse.org/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/commands/operations/IUndoableOperation.html org.eclipse.core.commands.operations.IUndoableOperation].
  
 
==== ContentPolicy ====
 
==== ContentPolicy ====

Revision as of 04:31, 8 June 2015

Note to non-wiki readers: This documentation is generated from the Eclipse wiki - if you have corrections or additions it would be awesome if you added them in the original wiki page.


Introduction

The GEF4 MVC component provides support for building up graphical editors and views based on a model-view-controller architecture and is the intended replacement for GEF (MVC) 3.x. It is internally composed out of four modules, which provide toolkit-independent base abstractions and implementations (MVC), JavaFX-specific specializations (MVC.FX), and Eclipse UI-integration for both (MVC.UI, MVC.FX.UI). In addition there is a deployed MVC Logo Example.

GEF4-Components-MVC.png


MVC

  • feature: org.eclipse.gef4.mvc
  • bundle: org.eclipse.gef4.mvc

The MVC module of GEF4 MVC offers those core concepts that are independent of any concrete rendering toolkit as well as of the Eclipse UI. As indicated by its name, the module provides a model-view-controller architecture that can be used to build up graphical editors and views. In good tradition with GEF (MVC) 3.x, 'controllers' are referred to as 'parts' (while the term 'visual part' instead of 'edit part' is used here, to depict that the MVC framework is not limited to editors alone).

A graphical application is thus composed of one or more viewers, where each viewer (IViewer) is populated by a set of visual parts (IVisualPart), which control the visuals that are rendered inside the viewer's controls. Those of the visual parts, which are responsible of controlling to be visualized contents, are referred to as content parts (IContentPart). They are accompanied by feedback parts (IFeedbackPart) and handle parts (IHandlePart), which do not control visualized contents but feedback or handle visuals that are needed for user interaction. All visual parts are arranged in a hierarchy (which resembles the hierarchy of visuals), which is rooted by a 'root part' (IRootPart).

Besides the parent-child relationship that establishes the hierarchy, visual parts may also be related to each other by means of an anchorage-anchor relationship. That is, a visual part that is placed at an arbitrary location within the hierarchy may be anchored on another anchorage part. As the visual part hierarchy has to correspond to the visual hierarchy, this mechanism is very useful when parts that control visuals that are placed in arbitrary places within the visual hierarchy have to be related to each other. In a graphical application that usually organizes visuals into layers, it can for instance be intensively used to update feedback or handles. By explicitly anchoring a feedback part on an underlying (anchorage) target content part, the feedback part inter alia obtains the necessary hooks to listen for changes of the content part visual (e.g. a position change) and to update its own feedback visual accordingly.

Tools (ITool) are used to interact with the parts inside a viewer. Each tool should be responsible of handling a certain interaction gesture (e.g. mouse click/drag or touch-based pinch/spread), by locating respective target parts (e.g. via hit-testing on the visual) and forwarding the interaction to them. While a tool should not have own interaction logic, it is responsible of handling the interaction, to which several parts may contribute e.g. by updating their contents, as a whole. That is, the tool has to ensure that all content modifying operations that result from a certain interaction, are executed in a single (undoable) transaction. As an interaction may span several viewers (e.g. a drag/drop operation), tools are bound to a domain (IDomain), to which also all viewers that make up a graphical application are bound, that maintains a global operation history and facilities to initialize and commit transactions.

The handling of an interaction is not performed directly by the target visual parts themselves, but by respective (interaction) policies (IPolicy) that are bound to them. An interaction policy is a strategy that encapsulates a certain (exchangeable) interaction logic, related to a gesture (e.g. what to do on click/drag). The active tool that handles an interaction takes this into account when forwarding the interaction, as it locates target parts also by evaluating their supported policies, and interacts with these policies directly. An (interaction) policy may handle an interaction directly, e.g. by manipulating the viewer state (e.g. changing the current selection when the target part gets clicked). It may also delegate to certain (transaction) policies that manipulate the contents as a result of an interaction (and have to do this by means of executing operations within the currently active transaction, the respective interaction tool has opened via the domain).

The viewer state (e.g. the current selection), which might be manipulated as the result of an interaction, is represented by means of dedicated models (ContentModel, SelectionModel, ViewportModel, etc.), which are bound to each viewer. As changes to the viewer state, as well as to the visualized contents, may lead to necessary viewer updates as well, behaviors (Behavior) may be bound to parts similar to policies. In contrast to policies, behaviors are active themselves, that is they will actively listen for changes (e.g. newly added content). Behaviors are also responsible of creating and disposing respective visual parts as needed (e.g. to update selection feedback as a result of changes to the selection model).


{Root}

  • package: org.eclipse.gef4.mvc

The {Root} package contains a com.google.inject.Module] that defines default bindings for MVC.

GEF4-MVC-root.png

MvcModule

The MvcModule defines methods to register bindings for different types (IBehavior, IVisualPart, etc.) which can be refined (overridden) by sub-classes. Additionally, it registers bindings for the ContentModel, ViewportModel, and GridModel.


Behaviors

  • package: org.eclipse.gef4.mvc.behaviors

The Behaviors package contains the IBehavior and AbstractBehavior definitions. Additionally, it provides various IBehavior implementations and a related utility class.

GEF4-MVC-behaviors.png

IBehavior, AbstractBehavior

Every IBehavior is bound to an IVisualPart, referred to as the host of the behavior. A behavior is meant to be registering change listeners on a model (e.g. SelectionModel, ContentModel, etc.) during its activation (and unregistering them during its deactivation). It will then update another model (e.g. the visualization) based on the changes to the first model. For example, the SelectionBehavior registers a listener on the SelectionModel and generates (or removes) selection feedback based on the changes reported by the listener.

The AbstractBehavior handles activation and provides methods to add/remove feedback and handle parts using the IFeedbackPartFactory and IHandlePartFactory of the IViewer.

BehaviorUtils

The BehaviorUtils class provides utility methods for establishing/unestablishing anchored-anchorage relations. These methods are used by the AbstractBehavior when adding/removing feedback or handles.

ContentBehavior, ContentPartPool

The ContentBehavior is listening for ContentModel changes to initiate a content synchronization upon changes. During a content synchronization, the currently active content parts are checked against the current content objects, i.e. content parts are created or removed based on the parent-child and anchored-anchorage relations between the content objects as defined by the content parts.

A content part that is removed is stored in a ContentPartPool, so that it can be re-used if it is needed later, and does not have to be re-created.

HoverBehavior

The HoverBehavior reacts to HoverModel changes. It can be bound to all content parts that should generate feedback/handles when the mouse hovers the part.

SelectionBehavior

The SelectionBehavior reacts to SelectionModel changes. It can be bound to all content parts that should generate feedback/handles when the part is selected.


Domain

  • package: org.eclipse.gef4.mvc.domain

The Domain package contains the IDomain abstraction and its related AbstractDomain realization.

GEF4-MVC-domain.png

IDomain, AbstractDomain

The IDomain represents the collective state of a graphical application, i.e. it is composed of all IViewers and ITools. Additionally, the IDomain provides an org.eclipse.core.commands.operations.IOperationHistory and org.eclipse.core.commands.operations.IUndoContext, which are used by policies to change the state of the application.


Models

  • package: org.eclipse.gef4.mvc.models

The Models package contains all viewer models, i.e. the data constituting a viewer state.

GEF4-MVC-models.png

ContentModel

The ContentModel stores the viewer's contents, i.e. the data that is processed by your application.

FocusModel

The FocusModel stores the IVisualPart with keyboard focus, i.e. the part that will receive all keyboard input.

GridModel

The GridModel stores the viewer's background grid settings:

  • snap-to-grid, true or false, indicates whether the visualization should snap to grid points.
  • show-grid, true or false, indicates whether to show the grid, or not.
  • zoom-grid, true or false, indicates whether to zoom the grid, or not.
  • grid-cell-width, Double, specifies the width of grid cells.
  • grid-cell-height, Double, specifies the height of grid cells.

HoverModel

The HoverModel stores the currently hovered IVisualPart.

SelectionModel

The SelectionModel stores all currently selected IContentParts.

ViewportModel

The ViewportModel stores the current viewport information, i.e. a scroll offset and a viewport transformation.


Operations

  • package: org.eclipse.gef4.mvc.operations

The Operations package contains implementations of IUndoableOperation which can be used to manipulate the default models, especially content creation and removal.

GEF4-MVC-operations.png

AbstractCompositeOperation

The AbstractCompositeOperation is the base class for two concrete org.eclipse.core.commands.operations.ICompositeOperation implementations: ForwardUndoCompositeOperation and ReverseUndoCompositeOperation.

AddContentChildOperation

The AddContentChildOperation can be used to add a content child to an IContentPart. It relies on the IContentPart's addContentChild() method for doing this.

This operation is the counterpart of the RemoveContentChildOperation.

AttachToContentAnchorageOperation

The AttachToContentAnchorageOperation can be used to attach an IContentPart to a content anchorage. It relies on the IContentPart's attachToContentAnchorage() method for doing this.

This operation is the counterpart of the DetachFromContentAnchorageOperation.

ChangeFocusOperation

The ChangeFocusOperation can be used to set the currently focused part by manipulating the FocusModel.

ChangeHoverOperation

The ChangeHoverOperation can be used to set the currently hovered part by manipulating the HoverModel.

ChangeSelectionOperation

The ChangeSelectionOperation can be used to set the currently selected parts by manipulating the SelectionModel.

ClearHoverFocusSelectionOperation

The ClearHoverFocusSelectionOperation can be used to clear the HoverModel, FocusModel, and SelectionModel, i.e. no parts will be focused, hovered, or selected after executing this operation.

DetachFromContentAnchorageOperation

The DetachFromContentAnchorageOperation can be used to detach an IContentPart from a content anchorage. It relies on the IContentPart's detachFromContentAnchorage() method for doing this.

This operation is the counterpart of the AttachToContentAnchorageOperation.

ForwardUndoCompositeOperation

The ForwardUndoCompositeOperation is a specific AbstractCompositeOperation. It will execute(), redo(), and undo() its operations in the order they were added to the composite operation.

RemoveContentChildOperation

The RemoveContentChildOperation can be used to remove a content child from an IContentPart. It relies on the IContentPart's removeContentChild() method for doing this.

This operation is the counterpart of the AddContentChildOperation.

ReverseUndoCompositeOperation

The ReverseUndoCompositeOperation is a specific AbstractCompositeOperation. It will execute() and redo() its operations in the order they were added to the composite operation, however it will undo() its operations in reverse order.

SetRefreshVisualOperation

The SetRefreshVisualOperation can be used to enable/disable the #refreshVisual() method for a specific IVisualPart.

SynchronizeContentAnchoragesOperation

The SynchronizeContentAnchoragesOperation can be used to initiate a synchronization of the content anchorages and currently active IContentParts for a given anchored IContentPart.

SynchronizeContentChildrenOperation

The SynchronizeContentChildrenOperation can be used to initiate a synchronization of the content children and currently active IContentParts for a given parent IContentPart.

UnexecutableOperation

The UnexecutableOperation is an "empty" operation, i.e. it will not do anything. However, since it is unexecutable, every composite operation containing an UnexecutableOperation is unexecutable, too.

ITransactional

The ITransactional interface defines two methods init() and commit() which enclose a transaction. Therefore, an ITransactional can be used to retrieve an operation which performs specific changes. For example, an IPolicy that implements ITransactional would probably create an org.eclipse.core.commands.operations.IUndoableOperation within init(), manipulate that operation within other methods, and finally return it from commit().


Parts

  • package: org.eclipse.gef4.mvc.parts

The Parts package contains all abstractions related to controllers (aka parts) in a model-view-controller architecture. For each abstraction, a corresponding (abstract) realization is provided, from which specific controllers can be sub-classed.

GEF4-MVC-parts-abstractions.png

IVisualPart, AbstractVisualPart

The IVisualPart interface is the main MVC abstraction for controller objects, and therefore, controls a visual and handles user interaction. Visual parts are organized in a hierarchy, i.e. every part (except the root part) is associated with a parent part, and can control a number of children parts. Additional to the parent-child relations, visual parts can be part of anchored-anchorage relations, which are independent to the hierarchy, i.e. anchoreds and anchorages can be located at arbitrary places within the hierarchy.

Visual parts are adaptable, so that you can adapt policies and behaviors to them (as well as anything else if needed). This is an integral part of user interaction, because the tools will delegate input events to corresponding policies of the visual part which controls the event target (visual). Visual parts are also activatable. During activation/deactivation they will activate/deactivate their adapters.

Moreover, a IVisualPart is an org.eclipse.gef4.common.properties.IPropertyChangeNotifier, i.e. it will notify all registered listeners about the following property changes:

  • "active": This visual part was activated/deactivated.
  • "adapters": The adapters (policies, behaviors, etc.) of this visual part changed.
  • "parent": The parent of this visual part changed.
  • "children": The children of this visual part changed.
  • "anchorages": The anchorages of this visual part changed.
  • "anchoreds": The anchoreds of this visual part changed.

IRootPart, AbstractRootPart

The IRootPart interface is a specialization of the IVisualPart interface. There is exactly one IRootPart per IViewer. It contains all IContentParts, IFeedbackParts, and IHandleParts as children and manages the root visuals.

IContentPart, AbstractContentPart

The IContentPart interface is a specialization of the IVisualPart interface. Content parts are bound to content model elements, i.e. they provide a link to the model, and allow manipulations of the model via addContentChild(), removeContentChild(), attachToContentAnchorage(), and detachFromContentAnchorage().

IFeedbackPart, AbstractFeedbackPart

The IFeedbackPart interface is a specialization of the IVisualPart interface. Feedback parts are used to give visual feedback to the user during interactions. They are usually rendered on top of the content parts.

IHandlePart, AbstractHandlePart

The IHandlePart interface is a specialization of the IVisualPart interface. Handle parts are used for visual handles, which can be used for interaction, i.e. to manipulate elements. They are usually rendered on top of the feedback parts.

IContentPartFactory

The IContentPartFactory interface is part of a default mechanic in MVC: It is used during the content synchronization within the ContentBehavior to create new content parts. Therefore, if you want to use this default mechanic, you have to supply an IContentPartFactory suitable to your content model.

IFeedbackPartFactory

The IFeedbackPartFactory interface is part of a default mechanic in MVC: It is used for creating feedback parts within the default behaviors, i.e. in response to mouse hover or selection changes.

IHandlePartFactory

The IHandlePartFactory interface is part of a default mechanic in MVC: It is used for creating handle parts within the default behaviors, i.e. in response to mouse hover or selection changes.

PartUtils

The PartUtils class is a collection of utility methods when working with visual parts.


Policies

  • package: org.eclipse.gef4.mvc.policies

The Policies package contains the IPolicy abstraction, a related abstract base implementation (AbstractPolicy), and concrete implementations for the manipulation of the ContentModel, namely ContentPolicy, CreationPolicy, and DeletionPolicy.

GEF4-MVC-policies.png

IPolicy, AbstractPolicy

An IPolicy is similar to an IBehavior in that it is bound to an IVisualPart. However, behaviors start actions by themselves (they are active), while policies are always called from the outside (they are passive).

There are basically two kinds of policies, interaction and transaction policies. An interaction policy is called by a ITool to handle part of an interaction (e.g. click, drag). A transaction policy is one that may be used by other (interaction or transaction) policies to actually perform a visual or semantic operation (e.g. create model element). It has to implement the ITransactional interface , encapsulating the to be performed operation as an org.eclipse.core.commands.operations.IUndoableOperation.

ContentPolicy

The ContentPolicy is a transactional (see ITransactional) policy to handle content changes, i.e. adding/removing of content children, as well as attaching/detaching to/from content anchorages. Therefore, it can be used to retrieve an operation which performs the desired content changes.

CreationPolicy

The CreationPolicy is a transactional (see ITransactional) policy that handles the creation of new content objects using the ContentPolicy. Therefore, it can be used to retrieve an operation which performs the desired creations.

DeletionPolicy

The DeletionPolicy is a transactional (see ITransactional) policy that handles the deletion of existing content objects using the ContentPolicy. Therefore, it can be used to retrieve an operation which performs the desired deletions.


Tools

  • package: org.eclipse.gef4.mvc.tools

The Tools package contains the ITool abstraction and its related AbstractTool realization.

GEF4-MVC-tools.png

ITool, AbstractTool

An ITool delegates certein input events or model changes to a corresponding (interaction) policy.


Viewer

  • package: org.eclipse.gef4.mvc.viewer

The Viewer package contains the IViewer abstraction and the related AbstractViewer realization.

GEF4-MVC-viewer.png

IViewer, AbstractViewer

An IViewer is the container for a visual part hierarchy and provides a link to the domain.


MVC.FX

  • feature: org.eclipse.gef4.mvc.fx
  • bundle: org.eclipse.gef4.mvc.fx

The MVC.FX module of GEF4 MVC provides specializations of the abstractions and implementations provided by MVC, which are bound to JavaFX-based visualizations.


{Root}

  • package: org.eclipse.gef4.mvc.fx

The {Root} package contains a Guice Module with default bindings for MVC.FX.

GEF4-MVC-FX-root.png

MvcFxModule

The MvcFxModule extends MvcModule. It defines methods to register bindings for the JavaFX-specific extensions to MVC (AbstractFXVisualPart, FXViewer, etc.) which can be refined (overridden) by sub-classes. Additionally, it registers the following bindings per default:

  • AbstractFXContentPart adapter bindings: FXTransformProvider, ContentBehavior, HoverBehavior, SelectionBehavior, FXFocusBehavior, and ContentPolicy.
  • AbstractFXHandlePart adapter bindings: FXHoverOnHoverPolicy and HoverBehavior.
  • FXDomain adapter bindings: FXHoverTool, FXClickDragTool, FXTypeTool, FXRotateTool, FXPinchSpreadTool, FXScrollTool, and FXFocusTool.
  • FXRootPart adapter bindings: FXFocusAndSelectOnClickPolicy, FXMarqueeOnDragPolicy, FXHoverOnHoverPolicy, FXZoomOnScrollPolicy, FXZoomOnPinchSpreadPolicy, FXPanOnScrollPolicy, FXPanOnTypePolicy, FXRotateSelectedOnRotatePolicy, FXChangeViewportPolicy, ContentBehavior, SelectionBehavior, FXGridBehavior, and FXViewportBehavior.
  • FXViewer adapter bindings: IRootPart, FocusModel, HoverModel, and SelectionModel.

Behaviors

  • package: org.eclipse.gef4.mvc.fx.behaviors

The Behaviors package contains JavaFX/MVC.FX-specific IBehavior implementations.

GEF4-MVC-FX-behaviors.png

FXCursorBehavior

The FXCursorBehavior is listening for mouse and keyboard input, so that it can change the JavaFX mouse cursor when the user presses/releases a key while moving the mouse.

FXFocusBehavior

The FXFocusBehavior is listening for FocusModel changes and transfers them over to JavaFX.

FXGridBehavior

The FXGridBehavior is listening for GridModel changes in order to apply those changes to the GridLayout of the viewer.

FXHoverBehavior

The FXHoverBehavior is listening for HoverModel changes in order to generate feedback/handles when hovering a part.

FXViewportBehavior

The FXViewportBehavior is listening for ViewportModel changes and transfers them over to the ScrollPaneEx of the viewer.


Domain

  • package: org.eclipse.gef4.mvc.fx.domain

The Domain package contains a JavaFX-specific IDomain implementation, which does not provide own logic but is used as a target for adapter map bindings within MVC.FX.

GEF4-MVC-FX-domain.png

FXDomain

The FXDomain parameterizes the AbstractDomain with javafx.scene.Node, but does not extend it further. It is basically intended to provide a target for adapter bindings and adapter scoping (see GEF4 Common).


Operations

  • package: org.eclipse.gef4.mvc.fx.operations

The Operations package contains all IUndoableOperation implementations contributed by MVC.FX.

GEF4-MVC-FX-operations.png

FXBendOperation

The FXBendOperation can be used to manipulate the points constituting an FXConnection, i.e. its start point, way points, and end point. When manipulating the start or end point, it does also connect it to the IVisualPart under mouse when applicable.

FXChangeViewportOperation

The FXChangeViewportOperation can be used to manipulate the ViewportModel, i.e. the scroll offset and content transformation.

FXResizeNodeOperation

The FXResizeNodeOperation can be used to resize a JavaFX Node.

FXRevealOperation

The FXRevealOperation can be used to reveal an IVisualPart in its IViewer.

FXTransformOperation

The FXTransformOperation can be used to manipulate the transformation associated with an IVisualPart due to FXTransformProvider.


Parts

  • package: org.eclipse.gef4.mvc.fx.parts

The Parts package contains all IContentPart, IVisualPart, IFeedbackPart, and IHandlePart implementations and related classes.

AbstractFXContentPart

The AbstractFXContentPart is a specialization of the AbstractContentPart which establishes JavaFX Node as the visual root type. It does also register its whole visual hierarchy at the visual-part-map.

GEF4-MVC-FX-parts-contents.png

AbstractFXFeedbackPart, FXHoverFeedbackPart, FXSelectionFeedbackPart, FXSelectionLinkFeedbackPart, FXDefaultFeedbackPartFactory

The AbstractFXFeedbackPart is a specialization of the AbstractFeedbackPart which establishes JavaFX Node as the visual root type. It does also register a VisualChangeListener upon attachment to an anchorage which refreshes the feedback visual upon anchorage visual changes.

GEF4-MVC-FX-parts-feedback.png

The FXHoverFeedbackPart displays a feedback geometry in response to HoverModel changes.

The FXSelectionFeedbackPart displays a feedback geometry in response to SelectionModel changes and FocusModel changes.

The FXSelectionLinkFeedbackPart is a specialization of the FXSelectionFeedbackPart which displays a dashed feedback geometry in response to SelectionModel changes and FocusModel changes.

The FXDefaultFeedbackPartFactory uses FXHoverFeedbackPart, FXSelectionFeedbackPart, and FXSelectionLinkFeedbackPart for generating feedback if the associated geometry provider is bound as an adapter on the hovered/selected part.

AbstractFXHandlePart, AbstractFXSegmentHandlePart, FXCircleSegmentHandlePart, FXRectangleSegmentHandlePart, FXDefaultHandlePartFactory

The AbstractFXHandlePart is a specialization of the AbstractHandlePart which establishes JavaFX Node as the visual root type. It does also register a VisualChangeListener upon attachment to an anchorage which refreshes the handle visual upon anchorage visual changes.

GEF4-MVC-FX-parts-handles.png

The AbstractFXSegmentHandlePart is a specialization of the AbstractFXHandlePart which is bound to a segment of a poly-bezier handle geometry, represented by an array of BezierCurves. A segment index identifies that segment (0, 1, 2, ...). A segment parameter specifies the position of this handle part on the segment (0 = start, 0.5 = mid, 1 = end).

The FXCircleSegmentHandlePart is a specialization of the AbstractFXSegmentHandlePart which uses a JavaFX Circle for the handle visualization.

The FXRectangleSegmentHandlePart is a specialization of the AbstractFXSegmentHandlePart which uses a JavaFX Rectangle for the handle visualization.

The AbstractFXRootPart is a specialization of the AbstractRootPart which establishes JavaFX Node as the visual root type. It does also register the part as soon as a link to the IViewer is obtained.

The FXDefaultHandlePartFactory uses FXCircleSegmentHandlePart and FXRectangleSegmentHandlePart for generating handles if the associated geometry provider is bound as an adapter on the hovered/selected part.

FXRootPart

The FXRootPart provides a content layer, a feedback layer, and a handle layer in which the visuals of the corresponding parts are displayed. The feedback layer is above the content layer, and the handle layer is above the feedback layer.

GEF4-MVC-FX-parts-root.png

ChopBoxAnchorProvider, FXTransformProvider, VisualBoundsGeometryProvider, VisualOutlineGeometryProvider

The MVC.FX module provides a number of com.google.inject.Provider, which are used by several mechanisms:

GEF4-MVC-FX-parts-providers.png

The ChopBoxAnchorProvider provides an (anchorage) part for which it is bound as an adapter with an FXChopBoxAnchor, which will then be used to compute anchor positions for all parts which are anchored at the (anchorage) part.

The FXTransformProvider adds a JavaFX Affine to the transforms list of the visual of the part at which it is bound as an adapter. It does also allow access to that Affine. Several policies make use of this Affine to perform transformations.

The VisualBoundsGeometryProvider is a specialization of the VisualOutlineGeometryProvider which returns the bounds of the visual of the part to which it is bound as an adapter.

The VisualOutlineGeometryProvider provides an IGeometry based on the visualization of the part to which it is bound as an adapter.

FXPartUtils

GEF4-MVC-FX-parts-utils.png

Policies

  • package: org.eclipse.gef4.mvc.fx.policies

The Policies package contains all IPolicy implementations contributed by MVC.FX. These can be divided into transactional policies, which can be used to generate an operation that performs certain changes, and interaction policies, which are associated with certain user interactions (mouse click/drag, touch pinch/spread, etc.).

GEF4-MVC-FX-policies-interaction.png

AbstractFXOnClickPolicy, FXFocusAndSelectOnClickPolicy

An AbstractFXOnClickPolicy is called upon mouse click events by the FXClickDragTool. You can use it as an adapter on any IVisualPart for which mouse click interaction is desired, and you can also register multiple instances of AbstractFXOnClickPolicy on the same IVisualPart (with different adapter roles).

The FXFocusAndSelectOnClickPolicy focusses and selects the host part upon mouse click.

AbstractFXOnDragPolicy, FXMarqueeOnDragPolicy, FXRelocateOnDragPolicy

An AbstractFXOnDragPolicy is called during a mouse press-drag-release gesture by the FXClickDragTool. You can use it as an adapter on any IVisualPart for which mouse drag interaction is desired, and you can also register multiple instances of AbstractFXOnDragPolicy on the same IVisualPart (with different adapter roles).

The FXMarqueeOnDragPolicy can be used to span a marquee selection area using mouse drag to select multiple parts at once.

The FXRelocateOnDragPolicy relocates its host visual using the host's FXTransformPolicy when the host visual is dragged with the mouse.

FXBendOnSegmentHandleDragPolicy, FXResizeRelocateOnHandleDragPolicy, FXRotateSelectedOnHandleDragPolicy, FXScaleRelocateOnHandleDragPolicy

The FXBendOnSegmentHandleDragPolicy is an AbstractFXOnDragPolicy which can be applied to FXSegmentHandlePart. It uses the FXBendPolicy to manipulate the org.eclipse.gef4.fx.nodes.FXConnection visual of the first anchorage of the host FXSegmentHandlePart.

The FXResizeRelocateOnHandleDragPolicy resizes and relocates the first anchorage of its host on mouse drag. It is based on FXResizePolicy and FXTransformPolicy.

The FXRotateSelectedOnHandleDragPolicy rotates the selected parts on mouse drag. It is based on FXRotatePolicy.

The FXScaleRelocateOnHandleDragPolicy scales and relocates the visual of its host on mouse drag.

AbstractFXOnHoverPolicy, FXHoverOnHoverPolicy

An AbstractFXOnHoverPolicy is called upon mouse hover by the FXHoverTool. You can use it as an adapter on any IVisualPart for which mouse hover interaction is desired, and you can also register multiple instances of AbstractFXOnHoverPolicy on the same IVisualPart (with different adapter roles).

The FXHoverOnHoverPolicy hovers the host part upon mouse hover.

AbstractFXOnPinchSpreadPolicy, FXZoomOnPinchSpreadPolicy

An AbstractFXOnPinchSpreadPolicy is called during a pinch/spread touch gesture by the FXPinchSpreadTool. You can use it as an adapter on any IVisualPart for which pinch/spread touch interaction is desired, and you can also register multiple instances of AbstractFXOnPinchSpreadPolicy on the same IVisualPart (with different adapter roles).

The FXZoomOnPinchSpreadPolicy zooms the viewport with a touch pinch/spread gesture. It is based on FXChangeViewportPolicy.

AbstractFXOnRotatePolicy, FXRotateSelectedOnRotatePolicy

An AbstractFXOnRotatePolicy is called during a rotate touch gesture by the FXRotateTool. You can use it as an adapter on any IVisualPart for which rotate touch interaction is desired, and you can also register multiple instances of AbstractFXOnRotatePolicy on the same IVisualPart (with different adapter roles).

The FXRotateSelectedOnRotatePolicy rotates the selected parts with a touch rotate gesture. It is based on FXRotatePolicy.

AbstractFXOnScrollPolicy, FXPanOnScrollPolicy, FXZoomOnScrollPolicy

An AbstractFXOnScrollPolicy is called upon mouse wheel scrolling or during a touch scroll gesture by the FXScrollTool. You can use it as an adapter on any IVisualPart for which scroll interaction is desired, and you can also register multiple instances of AbstractFXOnScrollPolicy on the same IVisualPart (with different adapter roles).

The FXPanOnScrollPolicy changes the scroll offset of the ViewportModel upon mouse/touch scroll events. The scroll direction is inverted when holding the <Shift> key.

The FXZoomOnScrollPolicy zooms the viewport on mouse scroll or touch scroll. It is based on FXChangeViewportPolicy.

AbstractFXOnTypePolicy, FXDeleteSelectedOnTypePolicy, FXPanOnTypePolicy

An AbstractFXOnTypePolicy is called upon key presses and releases by the FXTypeTool. You can use it as an adapter on any IVisualPart for which keyboard interaction is desired, and you can also register multiple instances of AbstractFXOnTypePolicy on the same IVisualPart (with different adapter roles).

The FXDeleteSelectedOnTypePolicy is an AbstractFXOnTypePolicy which deletes the selected parts when pressing the <Delete> key.

The FXPanOnTypePolicy changes the scroll offset of the ViewportModel upon arrow key presses.

FXChangeViewportPolicy

The FXChangeViewportPolicy is a transactional policy that can be used to manipulate the ViewportModel (currently only zoom level changes).

FXTransformPolicy, FXResizePolicy, FXBendPolicy, FXRelocateConnectionPolicy

GEF4-MVC-FX-policies-transactional.png

The FXTransformPolicy is a transactional policy that can be used to transform the visual of its host.

The FXResizePolicy is a transactional policy that can be used to resize the visual of its host.

The FXBendPolicy is a transactional policy that can be used to manipulate the points constituting an org.eclipse.gef4.fx.nodes.FXConnection, i.e. its start point, way points, and end point. When moving a point the policy takes care of:

  • Removing overlaid neighbor points.
  • Re-adding temporarily removed neighbor points.
  • Reconnecting points to the IVisualPart under mouse when applicable.

Per default, the FXBendPolicy can only be applied to those IVisualParts which use org.eclipse.gef4.fx.nodes.FXConnection as their visual. This can be adjusted by sub-classing and overriding the corresponding #getConnection() method.

The FXRelocateConnectionPolicy is a specialization of FXTransformPolicy that can be applied to IVisualParts which use org.eclipse.gef4.fx.nodes.FXConnection as their visual. Per default, it transforms only those points of a connection that are not bound to an anchorage.

FXResizeRelocatePolicy, FXRotatePolicy, FXScaleRelocatePolicy

The FXResizeRelocatePolicy is a transactional policy that can be used to resize and relocate the visual of its host. It is based on FXResizePolicy and FXTransformPolicy.

The FXRotatePolicy is a transactional policy that can be used to rotate the visual of its host. It is based on FXTransformPolicy.

The FXScaleRelocatePolicy is a transactional policy that can be used to scale and relocate the visual of its host. It is based on FXTransformPolicy.


Tools

  • package: org.eclipse.gef4.mvc.fx.tools

The Tools package contains JavaFX-specific ITool implementations for different interactions (e.g. mouse drag).

GEF4-MVC-FX-tools.png

FXClickDragTool

The FXClickDragTool registers listeners for mouse click and drag interactions. The target IVisualPart is determined by searching the visual part hierarchy, beginning at the part that controls the visual, which was pressed, until a part is found that supports at least one AbstractFXOnClickPolicy or AbstractFXOnDragPolicy, respectively. In addition, the target part for a specific javafx.event.EventTarget can be specified explicitly to bypass the target part search, as follows:

// override drag target to let another part continue the interaction
getHost().getRoot().getViewer().getDomain().getAdapter(FXClickDragTool.class)
	.overrideTargetForThisInteraction(eventTarget, newDragTargetPart);

A target override can be specified at any time, and will be maintained for the current interaction (or the next interaction if the mouse is not pressed, currently). All target overrides are cleared when the mouse is released.

FXFocusTool

The FXFocusTool registers listeners for window focus events and changes the viewer-focused flag in the FocusModel accordingly.

FXHoverTool

The FXHoverTool registers listeners for mouse hover interaction, i.e. mouse enter and mouse exit events for visuals. The target IVisualPart is determined by searching the visual part hierarchy, beginning at the part that controls the visual, which was hovered, until a part is found that supports at least one AbstractFXOnHoverPolicy.

FXPinchSpreadTool

The FXPinchSpreadTool registers listeners for touch pinch/spread gesture interaction, i.e. moving two fingers apart or bringing them together (the default zoom gesture on many touch displays). The target IVisualPart is determined by searching the visual part hierarchy, beginning at the part that controls the visual, which was touched, until a part is found that supports at least one AbstractFXOnPinchSpreadPolicy.

FXRotateTool

The FXRotateTool registers listeners for touch rotate gesture interaction, i.e. moving two fingers around each other (or moving one finger around another). The target IVisualPart is determined by searching the visual part hierarchy, beginning at the part that controls the visual, which was touched, until a part is found that supports at least one AbstractFXOnRotatePolicy.

FXScrollTool

The FXScrollTool registers listeners for scroll interaction, which may either be mouse wheel scrolling, or touch scrolling, i.e. dragging two fingers up or down. The target IVisualPart is determined by searching the visual part hierarchy, beginning at the part that controls the visual, which was scrolled or touched, until a part is found that supports at least one AbstractFXOnScrollPolicy.

FXTypeTool

The FXTypeTool registers listeners for keyboard interaction. The currently focused (see FocusModel) IVisualPart is used as the target part for keyboard interaction if it supports at least one AbstractFXOnTypePolicy.


Viewer

  • package: org.eclipse.gef4.mvc.fx.viewer

The Viewer package contains a JavaFX-specific IViewer implementation.

GEF4-MVC-FX-viewer.png

FXViewer

The FXViewer is a JavaFX-specific IViewer implementation. It provides a org.eclipse.gef4.fx.nodes.FXGridLayer and a org.eclipse.gef4.fx.nodes.ScrollPaneEx, which are arranged so that the org.eclipse.gef4.fx.nodes.FXGridLayer is displayed behind the contents of the org.eclipse.gef4.fx.nodes.ScrollPaneEx.

ISceneContainer

The ISceneContainer interface abstracts from the fact, that a JavaFX application can be embedded into an SWT application, or run stand-alone. It is responsible for assigning the javafx.scene.Scene to the appropriate container (javafx.stage.Stage or javafx.embed.FXCanvas).

FXStageSceneContainer

The FXStageSceneContainer is an implementation of the ISceneContainer interface for JavaFX stand-alone applications.


MVC.UI

  • feature: org.eclipse.gef4.mvc.ui
  • bundle: org.eclipse.gef4.mvc.ui

The MVC.UI module of GEF4 MVC provides aspects for an integration into the Eclipse UI:

  • Binding the operation history from the Eclipse Workbench.
  • An UndoablePropertySheetPage for contribution to the Eclipse 'Properties' view.

{Root}

  • package: org.eclipse.gef4.mvc.ui

GEF4-MVC-UI-root.png

MvcUiModule

The MvcUiModule contains bindings for the Eclipse integration. Currently, only a binding for the org.eclipse.core.commands.operations.IOperationHistory of the Eclipse workbench is provided, so that operations executed in the context of an IDomain are undoable/redoable from the Eclipse UI.


Properties

  • package: org.eclipse.gef4.mvc.ui.properties

GEF4-MVC-UI-properties.png

UndoablePropertySheetPage, UndoablePropertySheetEntry

The UndoablePropertySheetPage is a org.eclipse.ui.views.properties.PropertySheetPage extension that allows to perform undo/redo of property value changes also in case the viewer/editor is not active.

The UndoablePropertySheetEntry provides undo support for changes made to org.eclipse.ui.views.properties.IPropertySource by the Eclipse 'Properties' view. Clients can construct a org.eclipse.ui.views.properties.PropertySheetPage and use this class as the root entry. All changes made to property sources displayed on that page will be done using the provided org.eclipse.core.commands.operations.IOperationHistory.

SetPropertyValueOperation

The SetPropertyValueOperation can be used to set or reset the value of a property. It is used by the UndoablePropertySheetEntry.

ContentPropertySourceAdapterFactory

The ContentPropertySourceAdapterFactory adapts the content model objects of IContentPart to org.eclipse.ui.views.properties.IPropertySource.


MVC.FX.UI

  • feature: org.eclipse.gef4.mvc.fx.ui
  • bundle: org.eclipse.gef4.mvc.fx.ui

The MVC.FX.UI module of GEF4 MVC provides JavaFX-specific aspects for an integration into the Eclipse UI.


{Root}

  • package: org.eclipse.gef4.mvc.fx.ui

The {Root} package contains a Guice Module which binds an org.eclipse.jface.viewers.ISelectionProvider and handles the construction of an FXCanvas to render the JavaFX scene graph.

GEF4-MVC-FX-UI-root.png

MvcFxUiModule

The MvcFxUiModule contains bindings for the JavaFX/Eclipse integration:


Parts

  • package: org.eclipse.gef4.mvc.fx.ui.parts

The Parts package contains spcific org.eclipse.ui.part.ViewPart and org.eclipse.ui.part.EditorPart implementations which wrap an FXCanvas.

GEF4-MVC-FX-UI-parts.png

The JavaFX-unrelated classes in this package will be moved to the MVC.UI module as outlined in Bugzilla #469478.

DefaultSelectionProvider

The DefaultSelectionProvider is a general purpose implementation of the org.eclipse.jface.viewers.ISelectionProvider interface.

FXEditor

The FXEditor is a org.eclipse.ui.part.EditorPart extension, which can be used to embed an editor, based on GEF4 MVC.FX, into the Eclipse UI.

FXEditorActionBarContributor

The FXEditorActionBarContributor is an org.eclipse.ui.part.EditorActionBarContributor extension, which lets the undo/redo action group of the corresponding org.eclipse.ui.part.IEditorPart contribute to the action bars.

FXView

The FXView is a org.eclipse.ui.part.ViewPart extension, which can be used to embed a viewer, based on GEF4 MVC.FX, into the Eclipse UI.

IFXCanvasFactory

The IFXCanvasFactory handles the construction of an FXCanvas to render the JavaFX scene graph.

SelectionForwarder

The SelectionForwarder forwards changes made to the SelectionModel to the Eclipse "Selection Service" and vice versa.


Properties

  • package: org.eclipse.gef4.mvc.fx.ui.properties

The Properties package contains helper classes for the integration and manipulation of properties within the Eclipse 'Properties' view.

GEF4-MVC-FX-UI-properties.png

AbstractFXColorPicker, FXColorPicker, FXSimpleGradientPicker, FXAdvancedGradientPicker

The AbstractFXColorPicker is a JavaFX visualization for a button which shows a currently selected color, and picks a new color when clicked. Picking the new color is handled by subclasses. The FXColorPicker provides an SWT control which displays an AbstractFXColorPicker and uses the system's org.eclipse.swt.widgets.ColorDialog to pick a new color.

GEF4-MVC-FX-UI-FXColorPicker-control.jpg

The FXSimpleGradientPicker provides an SWT control which displays two AbstractFXColorPicker to specify a simple gradient, and uses the system's org.eclipse.swt.widgets.ColorDialog to pick a new color.

GEF4-MVC-FX-UI-FXSimpleGradientPicker-control.jpg

The FXAdvancedGradientPicker should provide an SWT control which displays/allows the manipulation of an advanced gradient (i.e. more than 2 stops). Unfortunately, it is not completely implemented, yet (see Bugzilla #469491 for details).

FXFillCellEditor, FXFillPropertyDescriptor, FXFillSelectionDialog

The FXFillCellEditor is a org.eclipse.jface.viewers.DialogCellEditor extension, which displays a currently selected fill color and offers a button to change that fill color. It is used as the org.eclipse.jface.viewers.CellEditor by FXFillPropertyDescriptor.

GEF4-MVC-FX-UI-FXFillCellEditor-control.jpg

The FXFillSelectionDialog is org.eclipse.jface.dialogs.Dialog extension, which provides a menu to select a color or gradient. It is used by the FXFillCellEditor to change the fill.

GEF4-MVC-FX-UI-FXFillSelectionDialog-control.jpg


Viewer

  • package: org.eclipse.gef4.mvc.fx.ui.viewer

The Viewer package provides an ISceneContainer implementation for the propagation of a JavaFX Scene to an FXCanvas.

GEF4-MVC-FX-UI-viewer.png

FXCanvasSceneContainer

The FXCanvasSceneContainer is an ISceneContainer implementation for the embedding of a MVC.FX application into the Eclipse UI, using javafx.embed.swt.FXCanvas.


Migration from GEF (MVC) 3.x to MVC, MVC.FX, MVC.UI, MVC.FX.UI

GEF4 MVC was written completely from scratch. While some proven concepts have been transferred from GEF (MVC) 3.x, central concepts and mechanisms have been reworked. The most notable differences are:

  • More modularity, separating out Eclipse Workbench UI dependencies: While GEF (MVC) 3.x provided a single bundle (with Eclipse UI dependencies), GEF4 MVC clearly separates out those dependencies into the MVC.UI and MVC.FX.UI bundles, so that standalone graphical applications can be realized based on MVC and MVC.FX alone. Furthermore, rendering toolkit independent abstractions (provided by MVC) are now clearly separated from rendering toolkit (i.e. JavaFX) specific concretizations (provided by MVC.FX.
  • Usage of JavaFX instead of SWT/Draw2d.
  • Usage of adapter pattern throughout: While GEF (MVC) 3.x only used the Eclipse Platform provided adaptable pattern for Eclipse Workbench UI integration tasks (e.g. integration with properties view), this mechanism is used intensively within GEF4 MVC to configure the complete graphical application. That is, tools and viewers are adapted to the domain, viewer models and the root part are adapted to the viewer, policies and behaviors are adapted to visual parts.
  • Usage of dependency injection
  • Own visual parts for feedback and handles (compared to 'lightweight' feedback)
  • Separation of policies (passive, invoked by tools) and behaviors (active, listening for changes)
  • Separation of interaction policies (directly invoked by tools, related to interaction) and transaction policies (called by interaction policies, realize the content manipulation)
  • Pure interaction-gesture-based tools without own transactional logic (compared to monolithic 'selection tool'): In contrast to GEF (MVC) 3.x, where tools were dedicated to certain semantic operations (creation, selection, etc.), tools are now pretty dumb and dedicated to interaction gestures (click/drag, scroll, etc.), and forward all interactions to respective interaction policies. While the tools provides the transactional context (i.e. it opens and closes a respective operation via the domain, so that all operations that are executed as a result of the interaction can be undone together) they do not translate the gesture-based interaction into semantical operations themselves. This responsibility lies with the interaction policies alone. Where a GEF (MVC) 3.x application had thus to specialize one of the default tools to add different semantic behavior, this can now be achieved by registering different interaction policies, which is much more lightweight.

Back to the top