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 .
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.
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.
The {Root} package contains a Guice Module ( com.google.inject.Module) with default bindings for MVC.FX.
The
MvcFxBundle is the bundle activator of the MVC.FX bundle.
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.
The Behaviors package contains the IBehavior and AbstractBehavior definitions, as well as various IBehavior implementations.
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.
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.
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.
The
FocusBehavior is listening for
FocusModel changes and transfers them over to JavaFX.
The
GridBehavior is listening for
GridModel changes in order to apply those changes to the GridLayout of the
IViewer.
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.
The
SelectionBehavior reacts to
SelectionModel changes. The
RevealPrimarySelectionBehavior ensures that the primarily selected part is made visual within the viewport of the viewer.
The
SelectionBehavior reacts to
SelectionModel changes. It generates feedback/handles when the part is selected.
The
SnappingBehavior listens for
SnappingModel changes and generates 'alignment' feedback.
The Domain package contains contains the IDomain abstraction and a related default realization.
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.
The Gestures package contains the IGesture abstraction and its related AbstractGesture realization.
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).
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.
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.
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.
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.
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.
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).
The Handlers package contains contains the IHandler abstractions for various supported gestures as well as related default implementations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The
DeleteSelectedOnTypeHandler is an
IOnTypePolicy that deletes the selected parts when pressing the \<Delete\> key.
The
FocusAndSelectOnClickHandler is an
IOnClickHandler that focusses and selects the host part upon mouse click. It manipulates the
FocusModel and
SelectionModel.
The
HoverOnHoverHandler is an
IOnHoverHandler that hovers the host part upon mouse hover. It manipulates the
HoverModel.
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.
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.
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.
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.
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.
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.
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.
The
SelectAllOnTypeHandler is an
IOnTypeHandler that selects all content parts of the viewer.
The
SelectFocusedOnTypeHandler is an
IOnTypeHandler that selects/deselects the focus element on (select) key type. It manipulates the
FocusModel.
The
TranslateSelectedOnDragHandler is an
IOnDragHandler that relocates the host visual when dragging with the mouse. It is based on the
TransformPolicy of its host.
The
TraverseFocusOnTypeHandler is an
IOnTypeHandler that traverses the focus element on (tab) key type. It manipulates the
FocusModel.
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.
The Models package contains all viewer models, i.e. the data constituting a viewer state.
The
FocusModel stores the
IVisualPart with keyboard focus, i.e. the part that will receive all keyboard input.
The
GridModel stores the viewer's background grid settings:
true or
false, indicates whether to show the grid, or not.
true or
false, indicates whether to zoom the grid, or not.
Double, specifies the width of grid cells.
Double, specifies the height of grid cells.
The
HoverModel stores the currently hovered
IVisualPart.
The
SelectionModel stores all currently selected
IContentParts.
The
SnappingModel stores all currently available snapping locations, which is used to indicate alignment feedback.
The Operations package contains all IUndoableOperation implementations contributed by MVC.FX.
The
ITransactionalOperation is a specialization of
org.eclipse.core.commands.operations.IUndoableOperation.
An
ITransactionalOperationcan 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.
The
AbstractCompositeOperation is the base class for two concrete
org.eclipse.core.commands.operations.ICompositeOperation implementations:
ForwardUndoCompositeOperation is a specific
AbstractCompositeOperation. It will
execute(),
redo(), and
undo() its operations in the order they were added to the composite operation.
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.
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.
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.
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.
The
BendContentOperation allows to bend the content of an
BendableContentPart.
The
ChangeContentsOperation allows to exchange the contents hold by the
ContentModel.
The
ChangeFocusOperation can be used to set the currently focused part by manipulating the
FocusModel.
The
ChangeSelectionOperation can be used to set the currently selected part8s) by manipulating the
SelectionModel.
The
ChangeViewportOperation can be used to manipulate the
InfiniteCanvas of the content
FXViewer, i.e. the scroll offset and content transformation.
The
DeselectOperation can be used to clear the currently selected parts by manipulating the
SelectionModel.
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.
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.
The
ResizeContentOperation allows to resize the contents of an
ResizableContentPart.
The
ResizeOperation can be used to resize a
javafx.scene.Node.
The
RevealOperation can be used to reveal an
IVisualPart in its
IViewer.
The
SelectOperation can be used to manipulate the currently selected parts by manipulating the
SelectionModel.
The
SetRefreshVisualOperation can be used to enable/disable the
#refreshVisual() method for a specific
IVisualPart.
The
TransformContentOperation can be used to transform the content of an
ITransformableContentPart.
The
TransformVisualOperation can be used to manipulate the visual associated with an
ITransformableContentPart.
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.
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.
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.
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().
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.
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.
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.
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.
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, and
SnappingFeedbackPart are concrete feedback part implementations that are used for default feedback.
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.
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.
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.
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.
The
PartUtils class is a collection of utility methods when working with visual parts.
The Policies package contains the IPolicy abstraction, a related abstract base implementation ( AbstractPolicy), and concrete base implementations.
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.
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:
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.
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.
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.
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.
The
FocusTraversalPolicy is an
AbstractPolicy that supports changing the focus part according to a defined but exchangeable strategy.
The
ResizePolicy is an
AbstractPolicy that supports content resizing of
IResizableContentParts.
The
TransformPolicy is an
AbstractPolicy that supports content transformation of
ITransformableContentParts.
The
ViewportPolicy is a transaction policy that can be used to manipulate
org.eclipse.gef.fx.nodes.InfiniteCanvas of the content
InfiniteCanvasViewer.
The Providers package provides a number of com.google.inject.Provider or similar interfaces, which are used by several mechanisms:
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.
Provider<Affine> to transform the visual of an
IVisualPart.
Provider<IGeometry> to determine the position and shape of feedback and handle visuals.
The
DefaultAnchorProvider provides an anchor for a given (anchorage)
IVisualPart.
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.
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.
The
ISnappingLocationProvider provides snapping locations for alignment feedback. The
BoundsSnappingLocationProvider,
CenterSnappingLocationProvider, and
TopLeftSnappingLocationProvider provide different default behaviors.
The Viewer package contains the IViewer abstraction and a related default implementation.
An
IViewer is the container for an
IVisualPart hierarchy and provides a link to the
IDomain.
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.
The MVC.FX.UI module of MVC provides aspects for an integration into the Eclipse 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.
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.
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.
The
AbstractViewerAction and
AbstractViewerContributionItemare extensions of JFace
org.eclipse.jface.action.Action and
org.eclipse.jface.action.ContributionItem, which make them IAdaptable.Bound to an IViewer.
The
AbstractViewerActionGroup is an extension of
org.eclipse.ui.actions.ActionGroup, which can group AbstractViewerActions and AbstractViewerContributionsItems.
The
DeleteAction handles deletion based on the selected
IContentParts in the content viewer.
The
SelectAllAction handles selection of all
IContentParts in the content viewer.
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.
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.
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).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.
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.
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.
A specific IDirtyStateProvider that depends on an IOperationHistory.
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.
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.
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.
The Properties package provides support for integrating JavaFX-related cell editors into the Eclipse 'Properties' view.
The
IPropertySheetPageFactory interface allows to implement a factory to create an
org.eclipse.ui.views.properties.IPropertySheetPage for an
org.eclipse.ui.IWorkbenchPart.
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.
The
SetPropertyValueOperation can be used to set or reset the value of a property. It is used by the
UndoablePropertySheetEntry.
An
FXPaintPropertyDescriptor is a property descriptor that integrates an
org.eclipse.gef.fx.jface.FXPaintLabelProvider and
org.eclipse.gef.fx.jface.FXPaintCellEditor.
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.
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: