Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: The ManhattanConnectionRouter which is provided by org.eclipse.draw2d provided a good basis for drawing connections in our tooling but it had problems in a few situations. If you take a look at the image in diagram1.jpg you will notice the problems it has in drawing the connection between Component1 and Component2 (it appears behind Component3). We prefer to draw the connection around Component3 as shown in diagram2.jpg. You will also notice that the two connections between Component4 and Component5 and between Component4 and Component6 (in diagram1.bmp) have vertical portions which are very close to each other. We prefer to separate them more for clarity as shown in diagram2.bmp. More information: In order to implement our desired connection layout, we created class SCDLManhattanConnectionRouter that was based on the original ManhattanConnectionRouter from org.eclipse.draw2d. We would like to submit our implementation of the connection router (SCDLManhattanConnectionRouter) for consideration into the base eclipse code, and we are making our changes available as required under the Eclipse Public License. Please see the attachment called SCDLManhattanConnectionRouter.java for that implementation.
Created attachment 123913 [details] Diagram 1
Created attachment 123914 [details] Diagram 2
Created attachment 123915 [details] SCDLManhattanConnectionRouter.java
Created attachment 124564 [details] Variant of SCDLManhattanConnectionRouter.java
Why does SCDLManhattanConnectionRouter not extend the ManhattanConnectionRouter?
SCDLManhattanConnectionRouter is a copy of ManhattanConnectionRouter with some private methods tweaked.
(In reply to comment #6) > SCDLManhattanConnectionRouter is a copy of ManhattanConnectionRouter with some > private methods tweaked. OK, so why not just request some additional API with the existing ManhattanConnectionRouter , why contribute a new one?
That's why we are submitting our code here for you to do whatever you see fit, whether creating extra APIs or changing the existing behavior. We didn't have the time to go through the process earlier.
The functionality of this router depends on a number of supporting classes, such as SCDLPolylineConnection, that appear to be internal to IBM/Rational. The "variant" makes use of a different set of supporting classes, such as ComponentReferenceGroupingFigure, that also appear to be internal. I have no experience with Eclipse development, so perhaps I'm missing something, but what purpose do the Java file attachments serve if nobody else can compile them?
(In reply to comment #9) > The functionality of this router depends on a number of supporting classes, > such as SCDLPolylineConnection, that appear to be internal to IBM/Rational. > The "variant" makes use of a different set of supporting classes, such as > ComponentReferenceGroupingFigure, that also appear to be internal. I have no > experience with Eclipse development, so perhaps I'm missing something, but what > purpose do the Java file attachments serve if nobody else can compile them? I think these can be easily refactored to create a more general collision avoidance router. I like this implementation, it's very useful in heavily populated diagram.
