Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 488358

Summary:	Support orthogonal connection routing within FXBendConnectionPolicy
Product:	[Tools] GEF	Reporter:	Alexander Nyßen <nyssen>
Component:	GEF MVC	Assignee:	Matthias Wienand <matthias.wienand>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	matthias.wienand
Version:	0.2.0
Target Milestone:	4.0.0 (Neon) M6
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	488355, 488356
Bug Blocks:	488360

Description Alexander Nyßen

2016-02-24 02:37:10 EST

FXBendConnectionPolicy should provide support for orthogonal connection routing alternative to its currently supported control-point based bending. 

That is, when a connection is routed orthogonally, segment mid-point handles should be provided that allow to move respective connection segments, which includes "merging" two segments to a single segment (by aligning them to a straight-line). Further, quarter-point handles should be provided to allow creation of new segments (by splitting an existing segment). 

Start- and end-point handles are still needed, as they are required to connect/disconnect the connection. We should investigate whether it is required to manually move the anchor position on the outline of the shape through them as well (which is not possible currently, as it would require to a mechanism to manually override an anchor position), or whether its sufficient to "implicitly" move a start- and end-point only by moving the respective connection segment, and to use the start- and end-point handles only for connecting/disconnecting (in which case an anchor position will be automatically computed).

Comment 1 Matthias Wienand

2016-03-16 08:12:45 EDT

I pushed the following changes to origin/master:

- Determine if a Connection is point-based or segment-based depending on its IRouter, i.e. a Connection that uses an OrthogonalRouter is considered to be segment-based, all other Connections are considered to be point-based.
- Enable multiple point selection & manipulation.
- Fix overlay removal for multiple points.
- Constrain movement of orthogonal segments in their respective direction.
- Make control points explicit upon interaction and normalize them before commit.
- Open Connection API by changing the visibility of many IAnchor- & AnchorKey-related methods to public.
- Allow registering an IComputationStrategy per AnchorKey, so that one IAnchor can use different computation strategies for its anchoreds (so that the computation strategy can be exchanged for a Connection without changing it for other Connections).
- Generate selection handles for segment based connections: 1) mid-segment handles for moving a segment; 2) quarter-segment handles for creating a new segment/splitting a segment.
- Update feedback and handles during interaction so that it stays in sync with the Connection. Remove code that re-assigns segment indices to the existing handle parts.
- Add method to test if an anchor was inserted by a router (IRouter#isImplicitAnchor()) so that explicit anchors (set by the user) can be differentiated from implicit anchors (set by the router).
- Normalize connection when translating its anchorages (FXNormalizeOnDragPolicy).
- Ensure FXBendOperation is only changing explicit anchors.
- Add tests for the FXBendConnectionPolicy.

Therefore, orthogonal Connections can now be manipulated by the FXBendConnectionPolicy. However, there seems to be an issue with vertical segments that I still have to track down (they get disconnected sometimes). Moreover, no selection handles should be visible for small segments, because otherwise, the handles are placed above each other. I will resolve this ticket when these issues have been resolved.

Comment 2 Matthias Wienand

2016-03-18 05:18:41 EDT

I fixed errors within the normalization (infinite recursion) and within the segment overlay detection (unconnected end points/strange behavior). Moreover, I prevented the generation of creation handles for small segments. The code is published on the master branch, therefore, I resolve this ticket as fixed for 4.0.0 M6.