Bugzilla – Full Text Bug Listing
| Summary: | Forcing an edge direction toward the center of a node. | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Florian Barbin <florian.barbin> | ||||||||||
| Component: | Diagram | Assignee: | Florian Barbin <florian.barbin> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | laurent.redor | ||||||||||
| Version: | 1.0.0 | Keywords: | triaged | ||||||||||
| Target Milestone: | 2.0.0 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Linux | ||||||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=444734 https://bugs.eclipse.org/bugs/show_bug.cgi?id=448739 |
||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Florian Barbin
We take about "Border Node" and not "Bordered Node". There is a confusion in my previous comment. Patches waiting for review: https://git.eclipse.org/r/#/c/29413/ https://git.eclipse.org/r/#/c/29414/ https://git.eclipse.org/r/#/c/29415/ https://git.eclipse.org/r/#/c/30259/ https://git.eclipse.org/r/#/c/30641/ https://git.eclipse.org/r/#/c/30413/ https://git.eclipse.org/r/#/c/30808/ New patch set: https://git.eclipse.org/r/#/c/31082/ All the gerrit reviews are available here: https://git.eclipse.org/r/#/q/status:open+project:sirius/org.eclipse.sirius+branch:bug/437528_centered_edges,n,z In addition of automatic tests, some manual tests should be performed during the validation: * Move a rectilinear edge segment on a centered source and target => The edge segment should stay centered. * Move a rectilinear edge segment on a free source and target. * Create a straight edge (centered on its source and target) with multiple bendpoints. Convert it to rectilinear => The last edge segments should be centered. Merged on master. See http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/log/?qt=grep&q=437528 We identified an issue with the "Snape to Grid". If it activated, the edge follows the grid in priority and not the node center. https://git.eclipse.org/r/#/c/32932/ fix this issue Fixed with http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=3e7acc0a5429c7377c7f58d86d55954955b469ef. An additional test has to be performed manually since we were not able to drag and drop a rectilinear edge segement with SWTBot: * Create a new project in your workspace and import inside the files from /org.eclipse.sirius.tests.swtbot/data/unit/centeredEdge/ * Open the "moving" representation * Display the diagram Grid and set the Grid Spacing to 30px * Move the "node2" top-left corner toward the first Grid intersection (toward the north-west direction) * Change the "edge6" routing style to "Rectilinear" * Move the last edge segment on the "node2" top-left corner (the edge segment should be Snap by the grid) * When dropping the edge, it should retrieve its original location toward the "node2" center. Created attachment 247225 [details]
Test case container in container
* Import the test case and open the unique diagram
* Zoom on the diagram in a kind that you can scroll it toward the bottom-right.
* Move an edge segment on the edge between "eClass2" and "eClass4"
* The other bendpoints move too.
That was due to a wrong source and target absolute bounds computation with scrollbar and with at least one hierarchical level of containement.
https://git.eclipse.org/r/#/c/33561/4 fix the last issue The fix corresponding to review of comment 10 has been pushed on master: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=15ce2d42b50bc970ecd920dc23c4ba1cb5668763 There is still a not covered scenario. Steps to reproduce: * Import the project of https://bugs.eclipse.org/bugs/attachment.cgi?id=247232 * Open the diagram diagWithEdgeWithBendpoints * Select the green edge (between InterfaceA and InterfaceB) * Change its Centered properties to Both (via the Properties view in Style tab) * Resize the InterfaceB from north side KO: The edge does not move and does not pointed to center anymore. Probably a check of centered propery to add in org.eclipse.sirius.diagram.ui.internal.operation.ShiftEdgeIdentityAnchorOperation.handleTargetEdges(View, EditPart) and in org.eclipse.sirius.diagram.ui.internal.operation.ShiftEdgeIdentityAnchorOperation.handleSourceEdges(View, EditPart) The bug detected in comment 12 is here since the bug 441424. A proposition of fix is available here: https://git.eclipse.org/r/33865 Bug of comment 12 is fixed with http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=b27d3eb84b5dff91deec8e4890a84d246debfebd During validation of bug 444734. I noticed that there is a similar problem with the action ArrangeAll. Steps to reproduce: * Import the project of bug 444734 * Open the diagram "new testReconnect" * Select All * Unpin selected elements (all) * Launch Arrange all * The edge between eClass2 and eClass4 is no longer centered on eClass4 side (target side). Created attachment 247959 [details]
Test copy paste issue with rectilinear edges
A new issue during the copy paste has been detected.
Steps to reproduce:
* Import testCopyPasteEdge.zip test case.
* Open the "copyPaste" representation.
* Perform a copy paste layout on the same diagram.
* The two rectilinear edges become straight => KO
* The edge layout should be the same after the paste.
Created attachment 247962 [details]
Test repair on edge centering
If the edge centering property has been changed in the VSM, the repair refresh the centering property on the edgeStyle but the Edge bendpoints are still the same.
Step to reproduce:
* import the testRepairEdge.zip use case
* DO NOT open the representation
* Launch a repair on the aird file.
* Open the representation:
** There are two edges which should be centered but its not the case: only the edge style centering value has been changed. => KO
Comment 16 fixed by http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=a23ba9933aeaa788a4e8e416b37397a52fc4a4cc Comment 17 fixed by http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=5d7e211b662ebf3b410d86d05cbbc9d6372bcd81 Another KO scenario: * Import the project of bug 444734 * Open the diagram "new testReconnect" * Resize the border node eClass4 to the left * The edge is no longer centered The comment 15 issue is fixed by this commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=c7d3f03c9a8029ea281820de6520f377266aa20c Created attachment 248082 [details]
tabbarTest.zip
Another KO scenario with these steps:
* Import project "TabbarTest" from tabbarTest.zip
* Open the session
* Open the diagram "aaaa package entities"
* Select the connection "ref0"
* In the properties view, in tab Style, change the Centered property to Both
KO: The edge is not centered.
* After this, move the last segment to have the edge that arrives to the top of the target node (the edge is now centered).
* Resize the target node
KO: The edge is no longer centered.
The comment 19 issue is fixed by this commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=bc7cca665b5978b9d8f6d54b8371b5d87a3a50dc See https://git.eclipse.org/r/#/c/35324/ to fix Comment 21 The gerrit https://git.eclipse.org/r/#/c/35324/ fixes only the first part (first KO) of the Comment 21. We still have known issues about this feature: In the case of auto-size containers, we compute a wrong size in pure GMF coordinate system. That happens with long labels for instance since we do not compute the real label size according to the font name, the font-size, etc. According to these limitations, we have two identified cases where the edge centering could be wrong: * When performing an arrange-all (or selection) * When re-sizing one of the edge ends shape. These issues will be fixed as part of new bugzilla. Verified with Sirius 2.0.0-S20141024-041312 See bug 448739 Available in Sirius 2.0.0. |