Skip to main content

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

Jump to: navigation, search

Difference between revisions of "GEF/New and Noteworthy/3.7"

(33 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
* [http://www.eclipse.org/gef/newandnoteworthy/New-and-Noteworthy-30.html New and Noteworthy in 3.0]
 +
* [http://www.eclipse.org/gef/newandnoteworthy/New-and-Noteworthy-35.html New and Noteworthy in 3.5]
 +
* [[GEF/New and Noteworthy/3.6| New and Noteworthy in 3.6]]
 +
 +
== General ==
 +
 +
=== Improved Mac OS X compatibility (M3, M4, M5, M6) ===
 +
Special focus has been spent on resolving Mac specific inconsistencies. While some issues (e.g. proper key bindings) could be resolved directly within Draw2d/GEF, most of the problems were caused by underlying SWT inconsistencies, which were (identified by the GEF team and) resolved by the SWT team. Most notably, XOR painting mode is now supported by SWT on Mac Cocoa, which was the root cause for several issues on  this platform, e.g. the incorrect painting of feedback figures.
 +
 +
Even while this has not been enforced via plug-in dependencies, it is thus recommended to use GEF 3.7 in combination with SWT/Eclipse 3.7, because you will not profit from these fixes otherwise. See [https://bugs.eclipse.org/bugs/buglist.cgi?columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Ctarget_milestone;query_based_on=GEF_ALL_3.7;op_sys=Mac%20OS%20X;op_sys=Mac%20OS%20X%20-%20Cocoa;query_format=advanced;bug_status=RESOLVED;version=2.1;version=2.1.1;version=2.1.2;version=2.2;version=3.0;version=3.1;version=3.1.1;version=3.2;version=3.2.1;version=unspecified;version=3.3;version=3.4;version=3.2.2;version=3.3.1;version=3.3.2;version=3.5;version=3.6;version=3.5.1;version=3.5.2;version=3.6.1;version=3.7;product=GEF;target_milestone=3.7;target_milestone=3.7%20M2;target_milestone=3.7%20M3;target_milestone=3.7%20M4;target_milestone=3.7%20M5;target_milestone=3.7%20M6;target_milestone=3.7%20M7;known_name=GEF_ALL_3.7 bugzilla] for a complete list of all Mac-specific issues that are resolved in 3.7.
 +
 
== Draw2d==
 
== Draw2d==
  
=== Refactoring of Geometry API ===
+
=== Refactoring of Geometry API (M4) ===
 
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.
 
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.
 +
 +
=== Refactoring of FlowLayout and ToolbarLayout (M5) ===
 +
<code>OrderedLayout</code> was introduced as a new common superclass of <code>FlowLayout</code> and <code>ToolbarLayout</code>. As a consequence, <code>FlowLayoutEditPolicy</code> could be generalized and may now work with <code>OrderedLayout</code>, being no longer restricted to <code>FlowLayout</code> based figures alone. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=88884 88884] for details.
  
 
== GEF ==
 
== GEF ==
  
=== Refactoring of Layout and PrimaryDrag edit policies to remove duplicate code and allow better extensibility ===
+
=== Refactoring of LayoutEditPolicy, ConstrainedLayoutEditPolicy, and XYLayoutEditPolicy (M4) ===
TODO: add details
+
Layout edit policies have been refactored to remove duplicate code and allow better extensibility.
  
=== ResizeTracker and CreationTool ===
+
*<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 as follows:
 +
** 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 (M4) ===
 +
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 (M4) ===
 
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:
 
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:
  
Line 22: Line 67:
 
* <code>CreationTool#getMinimumSizeFor(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.
+
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 <code>CreationTool</code> could already be easily exchanged with a customized subclass by specifying a tool class upon construction of a <code>CreationToolEntry</code>, the <code>ResizableEditPolicy</code> was now enhanced to allow clients to specify a custom <code>ResizeTracker</code> as well, which will be used for all resize handles.
  
The logic example was enhanced to demonstrate how the new features can be used.
+
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 ===
+
=== Enhancement of MarqueeSelectionTool (M4) ===
 
<code>MarqueeSelectionTool</code> was enhanced to now offer the following default marquee behaviors:
 
<code>MarqueeSelectionTool</code> was enhanced to now offer the following default marquee behaviors:
 
* BEHAVIOR_CONNECTIONS_TOUCHED (supported since 3.1)
 
* BEHAVIOR_CONNECTIONS_TOUCHED (supported since 3.1)
Line 36: Line 81:
  
 
It was furthermore refactored to allow clients to customize marquee selection behavior via subclassing and overwriting one or more of the following methods:
 
It was furthermore refactored to allow clients to customize marquee selection behavior via subclassing and overwriting one or more of the following methods:
* performMarqueeSelect()
+
* <code>performMarqueeSelect()</code>
* calculateMarqueeSelectedEditParts()
+
* <code>calculateMarqueeSelectedEditParts()</code>
* isMarqueeSelectable(EditPart)
+
* <code>isMarqueeSelectable(EditPart)</code>
  
 
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:
 
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()
+
* <code>getCurrentMarqueeSelectionRectangle()</code>
* getCurrentSelectionMode()
+
* <code>getCurrentSelectionMode()</code>
  
 
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.
 
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.
  
=== MatchSizeAction ===
+
=== -Enhancement of MarqueeToolEntry (M4) ===
Similar to <code>MatchWidthAction</code> and <code>MatchHeightAction</code>, a concrete <code>MatchSizeAction</code> [[Image:MatchSizeAction.png]] was now made available (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=107916 107916]).
+
<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.
 +
 
 +
=== Exposition of MatchSizeAction (M4) ===
 +
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.
 +
 
 +
=== Refactoring/Exposition of UndoablePropertySheetEntry/UndoablePropertySheetPage (M6) ===
 +
<code>UndoablePropertySheetEntry</code> was refactored and opened for subclassing (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=91257 91257]). An <code>UndoablePropertySheetPage</code> was introduced, which uses the <code>UndoablePropertySheetEntry</code> as its root entry and additionally supports the undo/redo of changes in case the associated editor is currently inactive (because the property view is active) by delegating to the editor's undo and redo actions (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=287684 287684]). <code>SetValueCommand</code> and <code>ResetValueCommand</code> were refactored into a single <code>SetPropertyValueCommand</code>, which was exposed as well (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=130721 130721]).
  
[[Category:Tools_Project]]
 
 
[[Category:GEF]]
 
[[Category:GEF]]

Revision as of 14:59, 19 June 2012

General

Improved Mac OS X compatibility (M3, M4, M5, M6)

Special focus has been spent on resolving Mac specific inconsistencies. While some issues (e.g. proper key bindings) could be resolved directly within Draw2d/GEF, most of the problems were caused by underlying SWT inconsistencies, which were (identified by the GEF team and) resolved by the SWT team. Most notably, XOR painting mode is now supported by SWT on Mac Cocoa, which was the root cause for several issues on this platform, e.g. the incorrect painting of feedback figures.

Even while this has not been enforced via plug-in dependencies, it is thus recommended to use GEF 3.7 in combination with SWT/Eclipse 3.7, because you will not profit from these fixes otherwise. See bugzilla for a complete list of all Mac-specific issues that are resolved in 3.7.

Draw2d

Refactoring of Geometry API (M4)

Geometry API was refactored to guarantee consistency between integer-precision and double-precision version of Point/PrecisionPoint, Dimension/PrecisionDimension, and Rectangle/PrecisionRectangle. 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 124904, 142628, and 271235 for details.

Refactoring of FlowLayout and ToolbarLayout (M5)

OrderedLayout was introduced as a new common superclass of FlowLayout and ToolbarLayout. As a consequence, FlowLayoutEditPolicy could be generalized and may now work with OrderedLayout, being no longer restricted to FlowLayout based figures alone. See 88884 for details.

GEF

Refactoring of LayoutEditPolicy, ConstrainedLayoutEditPolicy, and XYLayoutEditPolicy (M4)

Layout edit policies have been refactored to remove duplicate code and allow better extensibility.

  • LayoutEditPolicy was enhanced by adding methods relevant for translations, used in all layout edit policies (removed duplicate code from subclasses):
    • Added getLayoutOrigin()(pulled up from ConstrainedLayoutEditPolicy)
    • Added translateFromAbsoluteToLayoutRelative(Translatable t) (synthesized from duplicated code spread throughout different layout edit policies)
    • Added translateFromLayoutRelativeToAbsolute(Translatable t) (synthesized from duplicated code spread throughout different layout edit policies)
  • ConstrainedLayoutEditPolicy was changed as follows:
    • Added createAddCommand(ChangeBoundsRequest request, EditPart child, Object constraint) as a replacement for createAddCommand(EditPart child, Object constraint), which was in turn deprecated (this is now handled similar as in case of change constraint commands).
    • Made createChangeConstraintCommand(EditPart child, Object constraint) concrete (empty body) and deprecated it to indicate that clients should instead createChangeConstraintCommand(ChangeBoundsRequest request, EditPart child, Object constraint)
    • Added getConstraintFor(Request request, GraphicalEditPart child, Rectangle rectangle), which subsumes the duplicate code fragments located in getConstraintFor(ChangeBoundsRequest request, GraphicalEditPart child) and getConstraintFor(CreateRequest request) before (both of these methods now delegate to the new method).
  • XYLayoutEditPolicy was changed as follows:
    • Replaced overwritten version of getConstraintFor(ChangeBoundsRequest request, GraphicalEditPart child) with an overwritten version of the newly introduced getConstraintFor(Request request, GraphicalEditPart child, Rectangle rect).

See 320852 for details.

Refactoring of Primary Drag Edit Policies (M4)

Primary drag edit policies were refactored to allow clients to easier provide custom handles and related select/drag/resize trackers.

  • NonResizableEditPolicy was changed by introducing hook methods to allow clients to customize the creation of handles and drag/select trackers used by them:
    • Added createDragHandle(List handles, int direction)
    • Added createMoveHandle(List handles, int direction)
    • Added createDragTracker(), which is used by createDragHandle(List handles, int direction) to construct the drag tracker for the created drag handle.
    • Added createSelectTracker(), which is used by createMoveHandle(List handles, int direction) to construct the select tracker for the created move handle.
  • ResizableEditPolicy was similarly changed by introducing the following methods:
    • Added createResizeHandle(List handles, int direction)
    • Added createResizeTracker(int), which is used by createResizeHandle(List handles, int direction) to create the resize tracker for the constructed resize handle.

The refactoring was performed in combination with the enhancement of ResizeTracker and CreationTool with support for constraints on resize and size-on-drop. See 67541 for details.

Enhancement of ResizeTracker and CreationTool (M4)

Extended ResizeTracker and CreationTool 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:

  • ResizeTracker#enforceConstraintsForResize(ChangeBoundsRequest)
  • CreationTool#enforceConstraintsForSizeOnDropCreate(CreateRequest)

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:

  • ResizeTracker#getMaximumSizeFor(ChangeBoundsRequest)
  • ResizeTracker#getMinimumSizeFor(ChangeBoundsRequest)
  • CreationTool#getMaximumSizeFor(CreateRequest)
  • CreationTool#getMinimumSizeFor(CreateRequest)

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 could already be easily exchanged with a customized subclass by specifying a tool class upon construction of a CreationToolEntry, the ResizableEditPolicy was now 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 67541 for details.

Enhancement of MarqueeSelectionTool (M4)

MarqueeSelectionTool 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 67991 for details.

-Enhancement of MarqueeToolEntry (M4)

MarqueeToolEntry has been enhanced to use different icons dependent on the marquee behavior of the tool.

  • MarqueeEntry Nodes.png BEHAVIOR_NODE_TOUCHED and BEHAVIOR_NODES_CONTAINED
  • MarqueeEntry Connections.png BEHAVIOR_CONNECTIONS_TOUCHED and BEHAVIOR_CONNECTIONS_CONTAINED
  • MarqueeEntry Nodes and Connections.png BEHAVIOR_NODES_TOUCHED_AND_RELATED_CONNECTIONS and BEHAVIOR_NODES_CONTAINED_AND_RELATED_CONNECTIONS

See 185960 for details.

Exposition of MatchSizeAction (M4)

Similar to MatchWidthAction and MatchHeightAction, a concrete MatchSizeAction MatchSizeAction.png was now made available.

The logic example was enhanced to demonstrate use of the new action. See 107916 for details.

Refactoring/Exposition of UndoablePropertySheetEntry/UndoablePropertySheetPage (M6)

UndoablePropertySheetEntry was refactored and opened for subclassing (see 91257). An UndoablePropertySheetPage was introduced, which uses the UndoablePropertySheetEntry as its root entry and additionally supports the undo/redo of changes in case the associated editor is currently inactive (because the property view is active) by delegating to the editor's undo and redo actions (see 287684). SetValueCommand and ResetValueCommand were refactored into a single SetPropertyValueCommand, which was exposed as well (see 130721).

Copyright © Eclipse Foundation, Inc. All Rights Reserved.