Note to non-wiki readers: This documentation is generated from the GEF@github.com wiki - if you have corrections or additions it would be awesome if you could contribute them to the original wiki page .

## Introduction

The MVC component provides support for building up graphical applications based on a model-view-controller architecture. It is internally composed out of two modules, which provide JavaFX-specific abstractions ( MVC.FX ) and a related Eclipse UI-integration ( MVC.FX.UI ). In addition there is a deployed MVC Logo Example.

## MVC.FX

- feature: org.eclipse.gef.mvc.fx
- bundle: org.eclipse.gef.mvc.fx

As indicated by its name, the MVC.FX module of MVC provides a model-view-controller architecture that can be used to build up graphical editors and views. It is bound to JavaFX but provides abstractions and implementations that are independent of the Eclipse UI.

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 visual parts that 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) that 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 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. position changes) and to update its own feedback visual accordingly.

A user interaction is comprised of one or more (interleaving) gestures, for example, a mouse-based press-drag-release gesture, or a touch-based pinch-spread gesture. Gestures ( IGesture) are thus used to interact with the parts inside a viewer. Each gesture comprises a continuous sequence of relevated events produced by a user via a single input device (while mouse events may contain information about pressed modifier keys, a key press-release gesture is considered to be conceptually independent). The gesture that initiates an interaction is responsible of determining the respective target part that can handle the interaction. The handling of an interaction is not performed directly by the target part, but by a Handler ( IHandler) that is bound to it. A handler is a (passive) strategy that encapsulates a certain undoable logic that is carried out by transactional operations, which might eventually be constructed by so-called policies. All gestures that are involved in an interaction take this into account, as they locate target parts by evaluating their supported handlers, and interacting with these handlers instead of the part itself. In case of mouse events, handler resolution is performed through hit-testing, while for keyboard interaction a respective 'focus' part is considered. By default, the initiating gesture will identify the interaction handler(s), and interleaving gestures will forward their events to this/these handler(s) in case it is/they are capable of handling the interaction. A handler may thus handle multiple (interleaving) gestures (e.g. pressing keys while dragging the mouse).

The response to an interaction is encapsulated into a (compound) operation, which is locally executed during the interaction to indicate 'live' feedback to the user. The active handler may handle the response to an interaction directly, e.g. by providing an operation that manipulates the viewer state (e.g. changing the current selection when the target part gets clicked), or it can delegate it to certain policies ( IPolicy). They are attached to parts as well and encapsulate certain 'shared' logic. The gesture that concludes the interaction is responsible of executing the (compound) operation in a single (undoable) transaction. As an interaction may span several viewers (e.g. a drag/drop operation), gestures are bound to a domain ( IDomain), which also all viewers that make up a graphical application are bound to. The domain maintains a global operation history and facilities to initialize and commit transactions.

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 (e.g. SelectionModel), 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 ( IBehavior) 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) and perform a certain. 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). In contrast to policies, the reactions performed by behaviors are not executed on the operation history and are thus not undoable.

### {Root}

- package: org.eclipse.gef.mvc.fx

The {Root} package contains a Guice Module ( com.google.inject.Module) with default bindings for MVC.FX.

#### MvcFxBundle

The `MvcFxBundle` is the bundle activator of the MVC.FX bundle.

#### MvcFxModule

The `MvcFxModule` defines methods that register certain default bindings, which can be refined (overridden) by sub-classes. It also defines a couple of (empty) hook methods for bindings that subclasses should define.

### Behaviors

- package: org.eclipse.gef.mvc.fx.behaviors

The Behaviors package contains the IBehavior and AbstractBehavior definitions, as well as various IBehavior implementations.

#### IBehavior, AbstractBehavior

An `IBehavior` is bound to an IVisualPart, referred to as the host of the behavior. It actively listens to changes (usually of a viewer model like the SelectionModel) that affect its host and encapsulates a (not undoable) reaction to these changes, like showing or hiding feedback or handles. The SelectionBehavior for instance listens to changes of the SelectionModel and generates (or removes) selection feedback and handles in case its host is selected or deselected. To support proper registration of listeners, `IBehavior` extends org.eclipse.gef.common.activate.IActivatable, so it is activated/deactivated by its host whenever the host itself is activated/deactivated. Registering and unregistering of listeners can thus be performed during activation and deactivation, respectively.

An `IBehavior` is similar to an IPolicy in that it is bound to an IVisualPart. However, policies are not active by themselves (they are always called from the outside). Further, the response of an `IBehavior` is not meant to be undoable, whereas the response of an IPolicy is.

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

#### ConnectionClickableAreaBehavior

The `ConnectionClickableAreaBehavior` controls the size of the connection's curve node (invisible) clickable area dependent on the zoom level. This allows to 'hit' connections even when the zoom level is very low.

#### ContentBehavior, ContentPartPool

Conceptually, the content parts manifest a 'projection' of the contents of a viewer towards its visualization. They are created recursively, beginning with those contents elements referred to by the viewer's contents property. By providing respective hook methods (getContentChildrenUnmodifiable() and getContentAnchoragesUnmodifiable()) each content part indicates for which child content elements additional content parts are to be created, and to which content parts it is to be attached. The `ContentBehavior` listens for content changes (on the viewer contents property as well as on the content children and anchorages of all content parts) to initiate a content synchronization. During a content synchronization, the currently existing content parts are checked against the current content objects, so that content parts are created or removed as needed, and respective parent-child and anchored-anchorage relations are established as inferred from the contents via the hook methods of 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.

#### FocusBehavior

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

#### GridBehavior

The `GridBehavior` is listening for GridModel changes in order to apply those changes to the GridLayout of the IViewer.

#### HoverBehavior, HoverIntentBehavior

The `HoverBehavior` and `HoverIntentBehavior` react to HoverModel changes. They are attached to the IRootPart and will handle creation of feedback and handles for transient hover (mouse moved over visual) and intended hover (mouse stays over visual). Usually, `HoverBehavior` will care about creation of feedback, while handles are created by `HoverIntentBehavior`.

#### RevealPrimarySelectionBehavior

The `SelectionBehavior` reacts to SelectionModel changes. The `RevealPrimarySelectionBehavior` ensures that the primarily selected part is made visual within the viewport of the viewer.

#### SelectionBehavior

The `SelectionBehavior` reacts to SelectionModel changes. It generates feedback/handles when the part is selected.

#### SnappingBehavior

The `SnappingBehavior` listens for SnappingModel changes and generates 'alignment' feedback.

### Domain

- package: org.eclipse.gef.mvc.fx.domain

The Domain package contains contains the IDomain abstraction and a related default realization.

#### IDomain, HistoricizingDomain

The `IDomain` represents the collective state of a graphical application, i.e. it is composed of all IViewers and IGesture. Additionally, the `IDomain` provides means to execute (undoable) transactions, which is used by gestures/handlers to change the state of the application.

The `HistoricizingDomain` is the default implementation of IDomain that internally uses an org.eclipse.core.commands.operations.IOperationHistory and an org.eclipse.core.commands.operations.IUndoContext to realize undoable transactions.

### Gestures

- package: org.eclipse.gef.mvc.fx.gestures

The Gestures package contains the IGesture abstraction and its related AbstractGesture realization.

#### IGesture, AbstractGesture

An `IGesture` delegates input events to corresponding (interaction) IHandlers, which are actually responsible of handling the interaction. An interaction usually consists of more than one gesture, so gestures may be interleaving. While each gesture maintains a list of active handlers, by default, a gesture resolves handlers by first checking the active handlers of already running gestures. All those handlers, which can also handle the new gesture (i.e. they implement the flag interface) will be considered as active handlers also by the new gesture. If at least one active handler has been resolved this way, no additional handlers will be resolved. Otherwise active handlers for the new scene are resolved as by the initial gesture).

#### ClickDragGesture

The `ClickDragGesture` 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 IOnClickHandler or IOnDragHandler, respectively.

#### HoverGesture

The `HoverGesture` 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 IOnHoverHandler. The HoverGesture also supports "hover intent", i.e. holding the mouse over a visual and keeping it still for some delay, which is used for the addition/removal of hover (intent) handles by default.

#### PinchSpreadGesture

The `PinchSpreadGesture` 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 IOnPinchSpreadHandler.

#### RotateGesture

The `RotateGesture` 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 IOnRotateHandler.

#### ScrollGesture

The `ScrollGesture` 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 IOnScrollHandler.

#### TypeStrokeGesture

The `TypeStrokeGesture` registers listeners for keyboard interaction. When resolving IOnTypeHandler and IOnStrokeHandler, the content part controlling the current focus figure will be used as a starting point (it should correspond to the current focus part of the FocusModel, as the focus figure is synchronized with it).

### Handlers

- package: org.eclipse.gef.mvc.fx.handlers

The Handlers package contains contains the IHandler abstractions for various supported gestures as well as related default implementations.

#### IHandler, AbstractHandler

An `IHandler` encapsulates the response to an interaction gesture into a transactional operation. The operation may be directly constructed or a policy may be used for this purpose.

#### IOnClickHandler

An `IOnClickHandler` is called upon mouse click events by the ClickDragGesture. You can use it as an adapter on any IVisualPart for which mouse click interaction is desired.

#### IOnDragHandler

An `IOnDragHandler` is called during a mouse press-drag-release gesture by the ClickDragGesture. You can use it as an adapter on any IVisualPart for which mouse drag interaction is desired.

#### IOnHoverHandler

An `IOnHoverHandler` is called upon mouse hover by the HoverGesture. You can use it as an adapter on any IVisualPart for which mouse hover interaction is desired.

#### IOnPinchSpreadHandler

An `IOnPinchSpreadHandler` is called during a pinch/spread touch gesture by the PinchSpreadGesture. You can use it as an adapter on any IVisualPart for which pinch/spread touch interaction is desired.

#### IOnRotateHandler

An `IOnRotateHandler` is called during a rotate touch gesture by the RotateGesture. You can use it as an adapter on any IVisualPart for which rotate touch interaction is desired.

#### IOnScrollHandler

An `IOnScrollHandler` is called upon mouse wheel scrolling or during a touch scroll gesture by the ScrollGesture. You can use it as an adapter on any IVisualPart for which scroll interaction is desired.

#### IOnStrokeHandler

An `IOnStrokeHandler` is called upon key presses and releases by the TypeStrokeGesture. You can use it as an adapter on any IVisualPart for which keyboard interaction is desired.

#### IOnTypeHandler

An `IOnTypeHandler` is called upon key presses and releases by the TypeStrokeGesture. You can use it as an adapter on any IVisualPart for which keyboard interaction is desired.

#### BendFirstAnchorageOnSegmentHandleDragHandler

The `BendFirstAnchorageOnSegmentHandleDragHandler` is an IOnDragHandler which can be applied to SegmentHandlePart to bend the host's first anchorage, i.e. manipulate the org.eclipse.gef.fx.nodes.Connection visual of the first anchorage of the host SegmentHandlePart. It uses the BendConnectionPolicy of the first anchorage.

#### BendOnSegmentDragHandler

The `BendOnSegmentDragHandler` is an IOnDragHandler that can be used to drag individual segments of a Connection with an orthogonal org.eclipse.gef.fx.nodes.OrthogonalRouter. It is based on the BendConnectionPolicy of its host.

#### DeleteSelectedOnTypeHandler

The `DeleteSelectedOnTypeHandler` is an IOnTypePolicy that deletes the selected parts when pressing the \<Delete\> key.

#### FocusAndSelectOnClickHandler

The `FocusAndSelectOnClickHandler` is an IOnClickHandler that focusses and selects the host part upon mouse click. It manipulates the FocusModel and SelectionModel.

#### HoverOnHoverHandler

The `HoverOnHoverHandler` is an IOnHoverHandler that hovers the host part upon mouse hover. It manipulates the HoverModel.

#### MarqueeOnDragHandler

The `MarqueeOnDragHandler` is an IOnDragHandler that can be used to span a marquee selection area covering multiple parts using mouse drag. It manipulates the SelectionModel.

#### PanOnStrokeHandler

The `PanOnStrokeHandler` is an IOnTypeHandler that changes the scroll offset of the org.eclipse.gef.fx.nodes.InfiniteCanvas of the content InfiniteCanvasViewer upon arrow key presses. It is based on the ChangeViewportPolicy of the IRootPart.

#### PanOrZoomOnScrollHandler

The `PanOrZoomOnScrollHandler` changes the scroll offset or zoom level of the org.eclipse.gef.fx.nodes.InfiniteCanvas of the content InfiniteCanvasViewer upon mouse/touch scroll events. It is based on the ChangeViewportPolicy of the IRootPart.

#### ResizeTransformSelectedOnHandleDragHandler

The `ResizeTransformSelectedOnHandleDragHandler` is an IOnDragHandler that can be applied to SegmentHandlePart to resize and relocate the first anchorage of its host on mouse drag. It is based on ResizePolicy and TransformPolicy of the selected parts.

#### ResizeTranslateFirstAnchorageOnHandleDragHandler

The `ResizeTranslageFirstAnchorageOnHandleDragHandler` is an IOnDragHandler that that can be applied to SegmentHandlePart to resize and transform the visual of its host's first anchorage on mouse drag. It is based on the ResizePolicy and TransformPolicy of the host's first anchorage.

#### RotateSelectedOnHandleDragHandler

The `RotateSelectedOnHandleDragPolicy` is an IFXOnDragPolicy that that can be applied to SegmentHandlePart to rotate the selected parts on mouse drag. It is based on the TransformPolicy of the selected parts.

#### RotateSelectedOnRotateHandler

The `RotateSelectedOnRotateHandler` is an is an IOnRotateHandler that rotates the selected parts with a touch rotate gesture. It is based on the TransformPolicy of the selected parts.

#### SelectAllOnTypeHandler

The `SelectAllOnTypeHandler` is an IOnTypeHandler that selects all content parts of the viewer.

#### SelectFocusedOnTypeHandler

The `SelectFocusedOnTypeHandler` is an IOnTypeHandler that selects/deselects the focus element on (select) key type. It manipulates the FocusModel.

#### TranslateSelectedOnDragHandler

The `TranslateSelectedOnDragHandler` is an IOnDragHandler that relocates the host visual when dragging with the mouse. It is based on the TransformPolicy of its host.

#### TraverseFocusOnTypeHandler

The `TraverseFocusOnTypeHandler` is an IOnTypeHandler that traverses the focus element on (tab) key type. It manipulates the FocusModel.

#### ZoomOnPinchSpreadHandler

The `ZoomOnPinchSpreadHandler` is an is an IOnPinchSpreadHandler that changes the scaling of the InfiniteCanvas of the content InfiniteCanvasViewer upon a touch pinch/spread gesture. It is based on the ChangeViewportPolicy of its host.

### Models

- package: org.eclipse.gef.mvc.fx.models

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

#### 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:

- 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.

#### SnappingModel

The `SnappingModel` stores all currently available snapping locations, which is used to indicate alignment feedback.

### Operations

- package: org.eclipse.gef.mvc.fx.operations

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

#### ITransactionalOperation

The `ITransactionalOperation` is a specialization of org.eclipse.core.commands.operations.IUndoableOperation.

An `ITransactionalOperation`can be queried for content relevance of a change via isContentRelevant(). This allows to filter out non-content related operations in the operation history. Further, an `ITransactionalOperation` should be safe against repeated execution. This is required, as they are continuously executed during an interaction to indicate 'live feedback'. Therefore, execute() and redo() should always transfer a given 'current' state to a dedicated 'final' state, while undo() should always transfer a 'current' state back to the 'initial' state (when the operation was created). After having been executed, an `ITransactionalOperation` will only be added to the operation history, if it actually had an effect. An isNoop() callback is provided to compare the 'initial' against the 'final' state in order to decide this.

#### AbstractCompositeOperation, ForwardUndoCompositeOperation, ReverseUndoCompositeOperation

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

- The `ForwardUndoCompositeOperation` is a specific AbstractCompositeOperation. It will `execute()`, `redo()`, and `undo()` its operations in the order they were added to the composite operation.
- 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.

#### 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.

#### BendVisualOperation

The `BendVisualOperation` can be used to manipulate the points constituting an Connection, 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.

#### BendContentOperation

The `BendContentOperation` allows to bend the content of an BendableContentPart.

#### ChangeContentsOperation

The `ChangeContentsOperation` allows to exchange the contents hold by the ContentModel.

#### ChangeFocusOperation

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

#### ChangeSelectionOperation

The `ChangeSelectionOperation` can be used to set the currently selected part8s) by manipulating the SelectionModel.

#### ChangeViewportOperation

The `ChangeViewportOperation` can be used to manipulate the InfiniteCanvas of the content FXViewer, i.e. the scroll offset and content transformation.

#### DeselectOperation

The `DeselectOperation` can be used to clear the currently selected parts by manipulating the SelectionModel.

#### 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.

#### 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.

#### ResizeContentOperation

The `ResizeContentOperation` allows to resize the contents of an ResizableContentPart.

#### ResizeOperation

The `ResizeOperation` can be used to resize a javafx.scene.Node.

#### RevealOperation

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

#### SelectOperation

The `SelectOperation` can be used to manipulate the currently selected parts by manipulating the SelectionModel.

#### SetRefreshVisualOperation

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

#### TransformContentOperation

The `TransformContentOperation` can be used to transform the content of an ITransformableContentPart.

#### TransformVisualOperation

The `TransformVisualOperation` can be used to manipulate the visual associated with an ITransformableContentPart.

### Parts

- package: org.eclipse.gef.mvc.fx.parts

The Parts package contains all abstractions related to controllers (aka parts) in a model-view-controller architecture. This includes IContentPart, IVisualPart, IFeedbackPart, IHandlePart, and IRootPart abstractions and related implementations.

#### IVisualPart, AbstractVisualPart

The `IVisualPart` interface is the main MVC.FX 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 gestures 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, an `IVisualPart` exposes observable properties for:

- `"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, LayeredRootPart

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.

The `LayeredRootPart` is the default implementation, which 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.

#### 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()`.

#### ITransformableContentPart

The `ITransformableContentPart` interface is to be implemented by IContentParts, which support transformations of their content. This is e.g. used to persist a translate operation.

#### IResizableContentPart

The `IResizableContentPart` interface is to be implemented by IContentParts, which support resize of their content. This is e.g. used to persist a resize operation.

#### IBendableContentPart

The `IBendableContentPart` interface is to be implemented by IContentParts, which support bending of their content (i.e. manipulation throw inserting or moving of bend points). This is e.g. used to persist a bend operation.

#### IContentPartFactory

The `IContentPartFactory` interface is part of a default mechanic in MVC.FX: 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.

#### 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.

#### FocusFeedbackPart, HoverFeedbackPart, SelectionFeedbackPart, SelectionLinkFeedbackPart, SnappingFeedbackPart

`FocusFeedbackPart`, `HoverFeedbackPart`, `SelectionFeedbackPart`, `SelectionLinkFeedbackPart`, and `SnappingFeedbackPart` are concrete feedback part implementations that are used for default feedback.

#### IFeedbackPartFactory, DefaultFocusFeedbackPartFactory, DefaultHoverFeedbackPartFactory, DefaultSelectionFeedbackPartFactory, DefaultSnappingFeedbackPartFactory

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

The `DefaultFocusFeedbackPartFactory`, `DefaultHoverFeedbackPartFactory`, `DefaultSelectionFeedbackPartFactory`, and `DefaultSnappingFeedbackPartFactory` use `FocusFeedbackPart`, `HoverFeedbackPart`, `SelectionFeedbackPart`, `SelectionLinkFeedbackPart`, and `SnappingFeedbackPart` for generating feedback.

#### 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.

#### AbstractSegmentHandlePart, CircleSegmentHandlePart, RectangleSegmentHandlePart, SquareSegmentHandlePart

The `AbstractSegmentHandlePart` is a specialization of the `AbstractHandlePart` 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 `CircleSegmentHandlePart` is a specialization of the `AbstractSegmentHandlePart` which uses a javafx.scene.shape.Circle for the handle visualization.

The `RectangleSegmentHandlePart` is a specialization of the `AbstractSegmentHandlePart` which uses a javafx.scene.shape.Rectangle for the handle visualization.

#### IHandlePartFactory, DefaultHoverIntentHandlePartFactory, DefaultSelectionHandlePartFactory

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

The `DefaultHoverIntentHandlePartFactory` and `DefaultSelectionHandlePartFactory` use `CircleSegmentHandlePart`, `RectangleSegmentHandlePart`, and `SquareSegmentHandlePart` for generating handles if the associated geometry provider is bound as an adapter on the hovered/selected part.

#### PartUtils

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

### Policies

- package: org.eclipse.gef.mvc.fx.policies

The Policies package contains the IPolicy abstraction, a related abstract base implementation ( AbstractPolicy), and concrete base implementations.

#### IPolicy, AbstractPolicy

An `IPolicy` is bound to an IVisualPart, referred to as the host of the policy. All policies are transactional, i.e. it may be used by other policies or handlers to actually perform a visual or semantic operation (e.g. create model element). It has to encapsulate the to be performed operation as an ITransactionalOperation.

An `IPolicy` is similar to an IBehavior in that it is bound to an IVisualPart. However, behaviors are active by themselves (they actively listen to changes), while policies are always called from the outside (they are passive). Further, the response of an `IPolicy` is meant to be undoable, whereas the response of an IBehavior is not.

The `AbstractPolicy` is the base class for all policies that perform undoable changes. The offer `init()`, `commit()`, and `rollback()`, which enclose an undoable transaction.

#### BendConnectionPolicy

The `BendConnectionPolicy` is an AbstractPolicy that can be used to manipulate the points constituting an org.eclipse.gef.fx.nodes.Connection, 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 `BendConnectionPolicy` can only be applied to those IVisualParts which use org.eclipse.gef.fx.nodes.Connection as their visual. This can be adjusted by sub-classing and overriding the corresponding `#getConnection()` method.

#### ContentPolicy

The `ContentPolicy` is an AbstractPolicy 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 an AbstractPolicy 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 an AbstractPolicy 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.

#### FocusTraversalPolicy

The `FocusTraversalPolicy` is an AbstractPolicy that supports changing the focus part according to a defined but exchangeable strategy.

#### ResizePolicy

The `ResizePolicy` is an AbstractPolicy that supports content resizing of IResizableContentParts.

#### TransformPolicy

The `TransformPolicy` is an AbstractPolicy that supports content transformation of ITransformableContentParts.

#### ViewportPolicy

The `ViewportPolicy` is a transaction policy that can be used to manipulate org.eclipse.gef.fx.nodes.InfiniteCanvas of the content InfiniteCanvasViewer.

### Providers

- package: org.eclipse.gef.mvc.fx.providers

The Providers package provides a number of com.google.inject.Provider or similar interfaces, which are used by several mechanisms:

- IBendableContentPart uses an `IAnchorProvider` to find an org.eclipse.gef.fx.anchors.IAnchor for an IVisualPart at which a point of an org.eclipse.gef.fx.nodes.Connection can be attached.
- ITransformableContentPart uses a `Provider<Affine>` to transform the visual of an IVisualPart.
- DefaultFocusFeedbackPartFactory, DefaultHoverFeebackPartFactory, DefaultSelectionFeedbackPartFactory and DefaultHoverIntentHandlePartFactory, DefaultSelectionHandlePartFactory use a `Provider<IGeometry>` to determine the position and shape of feedback and handle visuals.

#### IAnchorProvider, DefaultAnchorProvider

The `DefaultAnchorProvider` provides an anchor for a given (anchorage) IVisualPart.

#### TransformProvider

The `TransformProvider` adds an javafx.scene.transform.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 javafx.scene.transform.Affine, which is used by several (transaction) policies to perform transformations.

#### GeometricOutlineProvider, GeometricBoundsProvider, ShapeOutlineProvider, ShapeBoundsProvider

The `GeometricOutlineProvider` and `GeometricBoundsProvider` return the core geometry and related bounds of the visual of the part to which they are bound as an adapter.

The `ShapeOutlineProvider` and `ShapeBoundsProvider` do likewise for the visual (shape) outline and bounds.

#### ISnappingLocationProvider, BoundsSnappingLocationProvider, CenterSnappingLocationProvider, TopLeftSnappingLocationProvider

The `ISnappingLocationProvider` provides snapping locations for alignment feedback. The `BoundsSnappingLocationProvider`, `CenterSnappingLocationProvider`, and `TopLeftSnappingLocationProvider` provide different default behaviors.

### Viewer

- package: org.eclipse.gef.mvc.fx.viewer

The Viewer package contains the IViewer abstraction and a related default implementation.

#### IViewer

An `IViewer` is the container for an IVisualPart hierarchy and provides a link to the IDomain.

#### InfiniteCanvasViewer

The `InfiniteCanvasViewer` is a IViewer implementation that provides an org.eclipse.gef.fx.nodes.InfiniteCanvas as its visual control, to which the IRootPart adds respective top-level children.

## MVC.FX.UI

- feature: org.eclipse.gef.mvc.fx.ui
- bundle: org.eclipse.gef.mvc.fx.ui

The MVC.FX.UI module of 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.gef.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.

#### MvcFxUiModule

The `MvcFxUiModule` 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.

### Actions

- package: org.eclipse.gef.mvc.fx.ui.actions

The Actions package contains specific org.eclipse.jface.action.IAction and org.eclipse.jface.action.ContributionItem implementations for deleting, scrolling, and zooming, as well as specific related org.eclipse.ui.actions.ActionGroups.

#### AbstractViewerAction, AbstractViewerContributionItem

The `AbstractViewerAction` and `AbstractViewerContributionItem`are extensions of JFace org.eclipse.jface.action.Action and org.eclipse.jface.action.ContributionItem, which make them IAdaptable.Bound to an IViewer.

#### AbstractViewerActionGroup

The `AbstractViewerActionGroup` is an extension of org.eclipse.ui.actions.ActionGroup, which can group AbstractViewerActions and AbstractViewerContributionsItems.

#### DeleteAction

The `DeleteAction` handles deletion based on the selected IContentParts in the content viewer.

#### SelectAllAction

The `SelectAllAction` handles selection of all IContentParts in the content viewer.

#### AbstractZoomAction, ZoomInAction, ZoomOutAction, ZoomResetAction, ZoomComboContributionItem, ZoomScaleContributionItem, ZoomActionGroup

The `AbstractZoomAction` is an abstract base implementation for all actions that are related to zooming of the content viewer. `ZoomInAction`, `ZoomOutAction`, and `ZoomResetAction` provide concrete implementations based on it. The `ZoomComboContributionItem` and `ZoomScaleContributionItem` provide SWT combo and scales for adjusting the zoom level. The `ZoomActionGroup` combines the different zoom-related actions and contribution items into a single action group.

#### AbstractScrollAction, ScrollBottomLeftAction, ScrollBottomRightAction, ScrollCenterAction, ScrollTopLeftAction, ScrollTopRightAction, ScrollActionGroup

The `AbstractScrollAction` is an abstract base implementation for all actions that are related to scrolling of the content viewer's viewport. `ScrollBottomLeftAction`, `ScrollBottomRightAction`, `ScrollCenterAction`, `ScrollTopLeftAction`, and `ScrollTopRightAction` provide concrete implementations based on it. The `ScrollActionGroup` combines the different scroll-related actions into a single action group.

### Parts

- package: org.eclipse.gef.mvc.fx.ui.parts

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

The JavaFX-unrelated classes in this package will be moved to the [MVC.UI](MVC#mvcfxui) module as outlined in Bugzilla [\#469478](https://bugs.eclipse.org/bugs/show_bug.cgi?id=469478).

#### ISelectionProviderFactory

The `ISelectionProviderFactory` interface can be used to implement a factory that creates an org.eclipse.jface.viewers.ISelectionProvider for a given org.eclipse.ui.IWorkbenchPart. It is used in assisted injection.

#### ContentSelectionProvider

The `ContentSelectionProvider` is an implementation of the org.eclipse.jface.viewers.ISelectionProvider interface that provides the content elements of the currently selected IContentParts, and can select IContentParts based on their content elements.

#### IDirtyStateProvider, IDirtyStateProviderFactory

The `IDirtyStateProvider` defines an interface that can be used by an AbstractFXEditor to determine and mark the editor state. The `IDirtyStateProviderFactory` can be used to create an `IDirtyStateProvider` for a given org.eclipse.ui.IWorkbenchPart. It is used for assisted injection.

#### HistoryBasedDirtyStateProvider

A specific IDirtyStateProvider that depends on an IOperationHistory.

#### AbstractFXEditor

The `AbstractFXEditor` is a org.eclipse.ui.part.EditorPart extension, which can be used to embed an editor, based on 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.

#### AbstractFXView

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

### Properties

- package: org.eclipse.gef.mvc.fx.ui.properties

The Properties package provides support for integrating JavaFX-related cell editors into the Eclipse 'Properties' view.

#### IPropertySheetPageFactory

The `IPropertySheetPageFactory` interface allows to implement a factory to create an org.eclipse.ui.views.properties.IPropertySheetPage for an org.eclipse.ui.IWorkbenchPart.

#### 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.

#### FXPaintPropertyDescriptor

An `FXPaintPropertyDescriptor` is a property descriptor that integrates an org.eclipse.gef.fx.jface.FXPaintLabelProvider and org.eclipse.gef.fx.jface.FXPaintCellEditor.

## Migration from GEF4 MVC 1.x to GEF MVC 5.x

When rewriting GEF 3.x MVC we initially took much care of separating generic, rendering-toolkit-independent concepts (MVC) from JavaFX-specific aspects (MVC.FX). The motivation behind was to enable a potential reuse of generic concepts also for other rendering toolkits than JavaFX. As it turned out, this was not a wise decision, which is why we merged MVC with MVC.FX (and MVC.UI with MVC.FX.UI) when developing GEF MVC 5.x. As a consequence, several indirections have been removed and several implementation classes were merged. The 'FX'-prefix, which was used to differentiate JavaFX-specific implementations from core abstractions, was removed as well. Therefore, most of the migration consists of dropping type parameters and adapting names.

## Migration from GEF (MVC) 3.x to GEF4 MVC 1.x

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), 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.FX and MVC.FX alone. Furthermore, rendering toolkit independent abstractions (provided by MVC.FX) 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 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.