Community
Participate
Working Groups
For the feature desribed in the bug 424099, I developped JUnit tests to find common bendpoints between links (see class org.eclipse.papyrus.uml.diagram.common.tests.tests.CommonBendpointsTest) Currently a part of these tests are broken (see build result here https://hudson.eclipse.org/papyrus/job/Papyrus-Luna-Anchors-Tests/lastCompletedBuild/testReport/) After some investigation I found than the feature continues to work fine, but the existing diagram doesn't have the same display just after the opening of the diagram between old framework and new LinksLF framework. I think than a part of the bugs comes from bug 443586: [LinksLF] routing of link moves applying Snap To Grid/Unapplying snap to grid and reopening the model. Another part of the bug should comes from the new router implementation.
Created attachment 248658 [details] snapshot of the model without linkslf
Created attachment 248659 [details] the same model with LinksLF
Created attachment 248660 [details] the initial model
The label of the links move, but I think than it is not really a bug, it should come from the move on the anchor and the changes in the routing.
Created attachment 249044 [details] test4: Dashed line breakup (model bendpoints and anchors)
Created attachment 249045 [details] test4: Solid line breakup (model bendpoints and anchors)
Hello, I just attached 2 detailed screenshots for the Test4 (top-right corner of diagram) to explain what happens. So here, as you can see the positions of the 2 link anchors differs a lot and only common point they have in the model is the green bendpoint at around [660,300]. Before LinksLF the default rectilinear router while drawing the last recti-segment always prefers the last bendpoint position to anchor position, so the without linkLF the segment is always drawn from this green circle at [660, 300] to "somewhere at the bounds", ignoring position of the blue circle (anchor). With LinksLF we have enforced the routing preference for anchor position to bendpoint position, so now the segment is drawn from the blue/red circle to "somewhere at the endless line containing the previous link segment". This change of behavior is required to preserve the relative anchor positions when we move the node. As the old routing completely ignores the position of the anchor for last segment, I don;t see how we can both respect the requirement of "draw to anchors" and keep the old routing at the same time.
This bug can be marked as closed fixed
Created attachment 251216 [details] Model showing that the issue is not fixed. Actually, this bug is probably not closed. We found some cases for which the display is different. The model was created with 0.10.2, and still displays correctly in 1.0.x without LinksLF support, but is displayed wrong with LinksLF support. Vincent, can you reopen this bug?
(In reply to Alain Le Guennec from comment #9) > Created attachment 251216 [details] > Model showing that the issue is not fixed. > > Actually, this bug is probably not closed. > We found some cases for which the display is different. > The model was created with 0.10.2, and still displays correctly in 1.0.x > without LinksLF support, but is displayed wrong with LinksLF support. > Vincent, can you reopen this bug? I forgot to mention that this seems related to snap-to-grid (the model is displayed wrong when snap-to-grid is active, but is fine without it).
I reopen the bug, according to Alain comment.
Created attachment 251243 [details] Model to reproduce anchor-less router issues with scrollbars We just found another issue, even more impacting this time: Rectilinear routers that have no specific source/target anchors (but just bendpoint(s)) are drawn incorrectly in presence of scrollbars when LinksLF support is enabled (it is ok without LinksLF). To reproduce, open the attached model (see router-bug-step1.png), and progressively move the scrollbar of the diagram downwards, pressing F5 at intermediate positions to refresh. You can see that the connector is progressively "drifting" towards the edges of the ports it is connected to (see router-bug-step2.png), and when it reaches those edges, it goes completely crazy because the router is starting vertically (see router-bug-step3.png) Note that such "anchor-less" connectors can be created by D&D of a hidden connector from the browser, or using "show related links". On big diagrams, where scrollbars are always present, this completely wreaks havoc. Note also that this pb is not linked to snap-to-grid, contrary to the previous one, so there seems to be at least two different issues left.
Created attachment 251244 [details] router-bug-step1
Created attachment 251245 [details] router-bug-step2
Created attachment 251246 [details] router-bug-step3
(In reply to Alain Le Guennec from comment #15) > Created attachment 251246 [details] > router-bug-step3 FYI, these models have been created with a css stylesheet forcing the rectilinear style from the element creation.
(In reply to vincent lorenzo from comment #16) > (In reply to Alain Le Guennec from comment #15) > > Created attachment 251246 [details] > > router-bug-step3 > > FYI, these models have been created with a css stylesheet forcing the > rectilinear style from the element creation. Actually, the CSS is irrelevant in the "anchorless rectilinear routing with scrollbars" issue. You can reproduce it with the Papyrus-with-linkslf version trivially: -Create a block with a part and a delegating connectors connecting a port of the block to a port of the part, and make sure the block symbol is big enough to have scrollbars -Hide the connector -Redrop the connector onto the IBD (that's for the anchorless part of the issue) -move scrollbars and refresh the diagrams => You've got the same issue. It's true that SCADE System comes with a default theme that switch connectors to rectilinear mode by default, but it is not necessary to reproduce the issue in Papyrus.
(In reply to Alain Le Guennec from comment #17) > (In reply to vincent lorenzo from comment #16) > > (In reply to Alain Le Guennec from comment #15) > > > Created attachment 251246 [details] > > > router-bug-step3 > > > > FYI, these models have been created with a css stylesheet forcing the > > rectilinear style from the element creation. > > Actually, the CSS is irrelevant in the "anchorless rectilinear routing with > scrollbars" issue. > You can reproduce it with the Papyrus-with-linkslf version trivially: > -Create a block with a part and a delegating connectors connecting a port of > the block to a port of the part, and make sure the block symbol is big > enough to have scrollbars > -Hide the connector > -Redrop the connector onto the IBD (that's for the anchorless part of the > issue) > -move scrollbars and refresh the diagrams > => You've got the same issue. > > It's true that SCADE System comes with a default theme that switch > connectors to rectilinear mode by default, but it is not necessary to > reproduce the issue in Papyrus. I forgot the step "turn to rectilinear routing style" after the drop of the connector.
Created attachment 251396 [details] Model to reproduce spurious offset disruption In reply to comment 9 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=451504#c9). I managed to bug a small model with Papyrus 1.0.1 that, when loaded with the LinksLF version, has its layout severely disrupted. I think it is the same issue as in Comment #9, but it is clearer. It is not related to snap-to-grid (I have it turned off), nor to scrollbars, nor to CSS (no stylesheet). It seems related to the way the router eliminates superimposed segments in rectilinear mode. For some reasons, the LinksLF router seems to be introducing a little offset when computing some of the segments, which causes them not to be superimposed anymore, and so segment that were not displayed with stock 1.0.1 now wrongly get displayed with LinksLF. The same offset introduction also causes some ugly "stairs" in edges that were completely straight in 1.0.1 (same diagram illustrates both issues). FYI, the model was built with stock 1.0.1, with connectors initially in oblique mode then changed to rectilinear. You can turn them back to oblique mode in 1.0.1 to understand how they were built, purposely with superimposed segments that become invisible in rectilinear mode.
