This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 121206 - Source anchors do not interact well with edges in orthogonal routing
Summary: Source anchors do not interact well with edges in orthogonal routing
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Graph (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: issues@platform
Depends on:
Blocks: 105060
  Show dependency tree
Reported: 2007-11-05 17:18 UTC by Trey Spiva
Modified: 2010-04-01 14:45 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

An anchor on the target end of a ConnectionWidget (12.40 KB, application/octet-stream)
2007-11-05 17:19 UTC, Trey Spiva
An anchor on the source end of a ConnectionWidget (11.14 KB, application/octet-stream)
2007-11-05 17:20 UTC, Trey Spiva
Close up of anchor on the source end. (4.54 KB, application/octet-stream)
2007-11-05 17:20 UTC, Trey Spiva

Note You need to log in before you can comment on or make changes to this bug.
Description Trey Spiva 2007-11-05 17:18:02 UTC
I am trying to create a custom anchor shape.  I first started by coping one of the existing shapes (TriangleAnchorShape).  I noticed that if the shape is on 
the target side of the ConnectionWidget that everything will work correctly.

< See the TargetAnchor.png >

However if I put the shape on the source side, things do not work so well.  In the image below you can see that ConnectionWidget does not enter the shape 
from the bottom, but instead from the right side.  

< See the SourceAnchor.png >

Also as you can see from the next image the connector actually enters the shape from the right then does a 90 degree turn down. to the center of the 

< See the closeup.png >
Comment 1 Trey Spiva 2007-11-05 17:19:20 UTC
Created attachment 52542 [details]
An anchor on the target end of a ConnectionWidget
Comment 2 Trey Spiva 2007-11-05 17:20:03 UTC
Created attachment 52543 [details]
An anchor on the source end of a ConnectionWidget
Comment 3 Trey Spiva 2007-11-05 17:20:55 UTC
Created attachment 52544 [details]
Close up of anchor on the source end.
Comment 4 Trey Spiva 2007-11-05 17:23:59 UTC
Response from David Kaspar:

This is caused by the routing algorithm. Here is what the validation
logic works:

1) ConnectionWidget realized that it has to be be re-routed.
2) ConnectionWidget ask router to route the path.
3) A router (in your case OrthogonalSearchRouter) asks source and target
anchor to compute a source and target location.
4) Then it routes a path independently on anchor-shapes. In your case
10px down, 50px right, 50px down.
5) ConnectionWidget repaints itself - the path is painted from the first
point to the last point but the first and last segments of the line are
cut at the distance defined in AnchorShape.getCutDistance.
6) ERROR - In your case the cutdistance is correctly set but only first
segment is cut at defined distance and at the same time the first
segment is just 10px long and therefore the second line start in the
middle of the anchor shape.

The only correct solution is to use a Router which routes a path that
has first and/or last segment long at least as
AnchorShape.getCutDistance + some space pixels (e.g. 5px).

This is actually possible by using a custom WidgetsCollisionCollector
(copy the class from the library). Then:
1) Change its implements section to: "ConnectionWidgetCollisionCollector"
2) Fix the signature of the "collectCollisions" method.
3) In the collectCollisions method improve the logic and add a bigger
collision rectangle in case that the collision Widget is fitting
following condition:
widget == connectionWidget.getSourceAnchor ().getRelatedWidget ()  ||
widget == connectionWidget.getTargetAnchor ().getRelatedWidget ()

This will assure that the router will create bigger the first and the
last segments of routed paths.
Comment 5 David Kaspar 2007-11-06 12:49:11 UTC
This is caused by the OrthogonalSearchRouter. It does not have "minimal-first-and-last-connection-segment-length"
property. Therefore following solutions could be done:
1) Introduce such parameter to the OrthogonalSearchRouter - requires API review
2) Extends the ConnectionWidgetCollisionCollector which calculate everything as normally but additionally it adds a
"bigger" vertical and horizontal collision for source and target widgets. The "bigger" means that the scene boundary of
those widgets will be enlarged by e.g. 20 pixels. Then the OrthogonalSearchRouter will route the first and the last
segment long enough.

Comment 6 David Kaspar 2008-08-18 10:27:17 UTC
The implementation of the minimal-fisrt/last-segment-length property is not simple. The workaround exists to use a
CollisionCollector that would produce represent source and target nodes as bigger collision areas.
Lowering to P3 since a workaround exists.