|
|
(23 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
− | == Draw2d==
| + | __NOTOC__ |
| | | |
− | === Refactoring of Geometry API ===
| + | The "New & Noteworthy" pages have been migrated to GitHub: |
− | Geometry API was refactored to guarantee consistency between integer-precision and double-precision version of <code>Point</code>/<code>PrecisionPoint</code>, <code>Dimension</code>/<code>PrecisionDimension</code>, and <code>Rectangle</code>/<code>PrecisionRectangle</code>. Synchronization between the still exposed integer-precision fields (x, y, width, height) and the no-longer exposed double-precision fields (preciseX, preciseY, preciseWidth, preciseHeight) is performed automatically by precision classes now, so clients may use the precision versions transparently, being no longer forced to perform a manual update of the respective fields. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=124904 124904], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=142628 142628], and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=271235 271235] for details.
| + | |
| | | |
− | == GEF ==
| + | * [https://github.com/eclipse/gef-legacy/blob/master/CHANGELOG.md#gef-370-indigo GEF-Legacy@github.com CHANGELOG] |
| | | |
− | === Refactoring of Layout Edit Policies ===
| |
− | Layout edit policies have been refactored to remove duplicate code and allow better extensibility.
| |
− |
| |
− | <code>LayoutEditPolicy</code> was enhanced by adding methods relevant for translations, used in all layout edit policies (removed duplicate code from subclasses):
| |
− | * Added <code>getLayoutOrigin()</code>(pulled up from <code>ConstrainedLayoutEditPolicy</code>)
| |
− | * Added <code>translateFromAbsoluteToLayoutRelative(Translatable t)</code> (synthesized from duplicated code spread throughout different layout edit policies)
| |
− | * Added <code>translateFromLayoutRelativeToAbsolute(Translatable t)</code> (synthesized from duplicated code spread throughout different layout edit policies)
| |
− |
| |
− | <code>ConstrainedLayoutEditPolicy</code> was changed as follows:
| |
− | * Added <code>createAddCommand(ChangeBoundsRequest request, EditPart child, Object constraint)</code> as a replacement for <code>createAddCommand(EditPart child, Object constraint)</code>, which was in turn deprecated (this is now handled similar as in case of change constraint commands).
| |
− | * Made <code>createChangeConstraintCommand(EditPart child, Object constraint)</code> concrete (empty body) and deprecated it to indicate that clients should instead <code>createChangeConstraintCommand(ChangeBoundsRequest request, EditPart child, Object constraint)</code>
| |
− | * Added <code>getConstraintFor(Request request, GraphicalEditPart child, Rectangle rectangle)</code>, which subsumes the duplicate code fragments located in <code>getConstraintFor(ChangeBoundsRequest request, GraphicalEditPart child)</code> and <code>getConstraintFor(CreateRequest request)</code> before (both of these methods now delegate to the new method).
| |
− |
| |
− | <code>XYLayoutEditPolicy</code> was changed to overwrite the
| |
− | * Replaced overwritten version of <code>getConstraintFor(ChangeBoundsRequest request, GraphicalEditPart child)</code> with an overwritten version of the newly introduced <code>getConstraintFor(Request request, GraphicalEditPart child, Rectangle rect)</code>.
| |
− |
| |
− | See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=320852 320852] for details.
| |
− |
| |
− | === Refactoring of Primary Drag Edit Policies ===
| |
− | Primary drag edit policies were refactored to allow clients to easier provide custom handles and related select/drag/resize trackers.
| |
− |
| |
− | <code>NonResizableEditPolicy </code> was changed by introducing hook methods to allow clients to customize the creation of handles and drag/select trackers used by them:
| |
− | * Added <code>createDragHandle(List handles, int direction)</code>
| |
− | * Added <code>createMoveHandle(List handles, int direction)</code>
| |
− | * Added <code>createDragTracker()</code>, which is used by <code>createDragHandle(List handles, int direction)</code> to construct the drag tracker for the created drag handle.
| |
− | * Added <code>createSelectTracker()</code>, which is used by <code>createMoveHandle(List handles, int direction)</code> to construct the select tracker for the created move handle.
| |
− |
| |
− | <code>ResizableEditPolicy</code> was similarly changed by introducing the following methods:
| |
− | * Added <code>createResizeHandle(List handles, int direction)</code>
| |
− | * Added <code>createResizeTracker(int)</code>, which is used by <code>createResizeHandle(List handles, int direction)</code> to create the resize tracker for the constructed resize handle.
| |
− |
| |
− | The refactoring was performed in combination with the enhancement of <code>ResizeTracker</code> and <code>CreationTool</code> with support for constraints on resize and size-on-drop. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=67541 67541] for details.
| |
− |
| |
− | === Enhancement of ResizeTracker and CreationTool ===
| |
− | Extended <code>ResizeTracker</code> and <code>CreationTool</code> so that they now offer means to enforce certain constraints (by default, minimum and maximum size constraints) during resize as well as size-on-drop (dragging during creation). This was realized by adding methods to enforce size constraints:
| |
− |
| |
− | * <code>ResizeTracker#enforceConstraintsForResize(ChangeBoundsRequest)</code>
| |
− | * <code>CreationTool#enforceConstraintsForSizeOnDropCreate(CreateRequest)</code>
| |
− |
| |
− | which are called whenever the source respectively target request is updated. By default, both ensure that minimum and maximum size constraints, which are inferred via respective hook methods:
| |
− |
| |
− | * <code>ResizeTracker#getMaximumSizeFor(ChangeBoundsRequest)</code>
| |
− | * <code>ResizeTracker#getMinimumSizeFor(ChangeBoundsRequest)</code>
| |
− | * <code>CreationTool#getMaximumSizeFor(CreateRequest)</code>
| |
− | * <code>CreationTool#getMinimumSizeFor(CreateRequest)</code>
| |
− |
| |
− | Clients may overwrite the respective hook methods to infer maximum and minimum sizes for certain requests, or overwrite and adjust the enforcement of constraints as a whole (in case additional constraints have to be ensured). While the CreationTool may easily be exchanged with a subclass by specifying a tool class upon construction of a CreationToolEntry, the ResizableEditPolicy was enhanced to allow clients to specify a custom ResizeTracker as well, which will be used for all resize handles.
| |
− |
| |
− | The logic example was enhanced to demonstrate how the new features can be used. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=67541 67541] for details.
| |
− |
| |
− | === MarqueeSelectionTool ===
| |
− | <code>MarqueeSelectionTool</code> was enhanced to now offer the following default marquee behaviors:
| |
− | * BEHAVIOR_CONNECTIONS_TOUCHED (supported since 3.1)
| |
− | * BEHAVIOR_CONNECTIONS_CONTAINED
| |
− | * BEHAVIOR_NODES_TOUCHED
| |
− | * BEHAVIOR_NODES_CONTAINED (supported since 3.1, default behavior)
| |
− | * BEHAVIOR_NODES_TOUCHED_AND_RELATED_CONNECTIONS
| |
− | * BEHAVIOR_NODES_CONTAINED_AND_RELATED_CONNECTIONS (supported since 3.1, formerly known as BEHAVIOR_NODES_AND_CONNECTIONS, which was in turn deprecated).
| |
− |
| |
− | It was furthermore refactored to allow clients to customize marquee selection behavior via subclassing and overwriting one or more of the following methods:
| |
− | * performMarqueeSelect()
| |
− | * calculateMarqueeSelectedEditParts()
| |
− | * isMarqueeSelectable(EditPart)
| |
− |
| |
− | The following methods are now also exposed (protected visibility) so clients can use access the current tool mode and the selection rectangle in their customization code:
| |
− | * getCurrentMarqueeSelectionRectangle()
| |
− | * getCurrentSelectionMode()
| |
− |
| |
− | The logic example was enhanced to demonstrate all new marquee behaviors. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=67991 67991] for details.
| |
− |
| |
− | === MarqueeToolEntry ===
| |
− | <code>MarqueeToolEntry</code> has been enhanced to use different icons dependent on the marquee behavior of the tool.
| |
− |
| |
− | * [[Image:MarqueeEntry_Nodes.png]] BEHAVIOR_NODE_TOUCHED and BEHAVIOR_NODES_CONTAINED
| |
− | * [[Image:MarqueeEntry_Connections.png]] BEHAVIOR_CONNECTIONS_TOUCHED and BEHAVIOR_CONNECTIONS_CONTAINED
| |
− | * [[Image:MarqueeEntry_Nodes_and_Connections.png]] BEHAVIOR_NODES_TOUCHED_AND_RELATED_CONNECTIONS and BEHAVIOR_NODES_CONTAINED_AND_RELATED_CONNECTIONS
| |
− |
| |
− | See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=185960 185960] for details.
| |
− |
| |
− | === MatchSizeAction ===
| |
− | Similar to <code>MatchWidthAction</code> and <code>MatchHeightAction</code>, a concrete <code>MatchSizeAction</code> [[Image:MatchSizeAction.png]] was now made available.
| |
− |
| |
− | The logic example was enhanced to demonstrate use of the new action. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=107916 107916] for details.
| |
− |
| |
− | [[Category:Tools_Project]]
| |
| [[Category:GEF]] | | [[Category:GEF]] |