Bugzilla – Full Text Bug Listing
| Summary: | Wrong draw2d (visible) border node location after resize | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Laurent Redor <laurent.redor> | ||||
| Component: | Diagram | Assignee: | Laurent Redor <laurent.redor> | ||||
| Status: | CLOSED FIXED | QA Contact: | Belqassim Djafer <belqassim.djafer> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | maxime.porhel, pierre-charles.david | ||||
| Version: | 0.9 | Keywords: | triaged | ||||
| Target Milestone: | 3.0.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: |
https://git.eclipse.org/r/47273 https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e65687f5d39bea2b79eb413a8f2fb89b6aa11025 |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
This problem occurs only in a specific case. Explanations: * The container C has 2 border nodes, A and B, on the west side. * The B y coordinate is higher than A. * B is resized to the bottom. * During the execution of the resize command (SpecificBorderItemSelectionEditPolicy.getResizeCommand) of B, the GMF bounds of B is set (SetBoundsCommand). Then , the draw2D uses the DBorderItemLocator to display these border nodes according to the GMF bounds. ** DBorderItemLocator locates A: *** It considers the current location of B with its new size. *** A is located just after B (even if it does not correspond to GMF bounds) to avoid overlap. ** DBorderItemLocator locates B: *** It considers the current location of A (just decided before). If the size bewteen the bottom of A and the bottom of C is enough, B is located just after A (even if it does not correspond to GMF bounds) to avoid overlap. Otherwise, B is located at its initial location (even if it does not correspond to GMF bounds). ** DBorderItemLocator relocates A: *** If the space has been released by B, A is located to the location corresponding to GMF bounds. Otherwise A keeps its wrong location. ** DBorderItemLocator relocates B: *** If the space has been released by A, B is located to the location corresponding to GMF bounds. Otherwise B keeps its wrong location. New Gerrit change created: https://git.eclipse.org/r/47273 (In reply to Laurent Redor from comment #1) > ** DBorderItemLocator locates A: > *** It considers the current location of B with its new size. The B has its new size because it is set during org.eclipse.sirius.diagram.ui.edit.internal.part.AbstractDiagramNodeEditPartRefreshVisualsOperation.refreshSize(). This method is called before the DBorderItemLocator. Gerrit change https://git.eclipse.org/r/47273 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e65687f5d39bea2b79eb413a8f2fb89b6aa11025 Resolved with above commit Verified with Sirius 3.0.0 RC1 Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0. |
Created attachment 253184 [details] WrongBorderItemLocatorTestCase.zip In some specific cases, when a border node is resized and overlap another one, the brother border nodes, the overlapped ones, are moved. KO: In this case, the brother border nodes must kept stable. Steps to reproduce: * Import projet Test from "WrongBorderItemLocatorTestCase.zip" (inspired from data of test /org.eclipse.sirius.tests.swtbot/src/org/eclipse/sirius/tests/swtbot/CenteredEdgesTest.java). * Open diagram "resizeBorderNode" * Resize the bottom side of "border2" (align it to the guide) * During resize, the feedback is under "border1": OK * But when the resize is applied, the resized "border1" is above "border2" and "border2" is moved: KO. The GMF constraint is OK but not draw2d constraint (what you see at screen).