Bug 521932

Summary: Possible wrong border node GMF coordinates after arrange all
Product: [Modeling] Sirius Reporter: Florian Barbin <florian.barbin>
Component: DiagramAssignee: Project Inbox <sirius.diagram-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: laurent.redor
Version: 5.0.0Keywords: triaged
Target Milestone: ---   
Hardware: PC   
OS: Linux   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=520624
https://git.eclipse.org/r/104470
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=995e100a7cb6dc8d086a19c0193331243c329667
Whiteboard:
Attachments:
Description Flags
Use case to reproduce this issue none

Description Florian Barbin CLA 2017-09-06 09:44:36 EDT
Created attachment 270097 [details]
Use case to reproduce this issue

With the attached project,
* Open the UseCase3 representation
* Perform an arrange all
* The border node C121 should be at the south location and its GMF coordinates are not consistent. (To check the GMF coordinates, install the Sirius Debug View)
Comment 1 Florian Barbin CLA 2017-09-06 09:53:06 EDT
Analysis:
* The problem is from org.eclipse.sirius.diagram.ui.graphical.edit.policies.SpecificBorderItemSelectionEditPolicy.getNewBounds(ChangeBoundsRequest) method.

This method uses DBorderItemLocator to compute the border node valid location. But in the case of an arrange all, the parent figure size is not yet computed and can be different at the end of the arrange all.

As the border node location has already been computed by using the CanonicalDBorderItemLocator, we should add a metadata in the ChangeBoundsRequest to do not use the DBorerItemLocator in SpecificBorderItemSelectionEditPolicy.getMoveCommand
Comment 2 Florian Barbin CLA 2017-09-06 10:02:04 EDT
Bug detected during the 520624
Comment 3 Eclipse Genie CLA 2017-09-06 10:55:15 EDT
New Gerrit change created: https://git.eclipse.org/r/104470
Comment 4 Florian Barbin CLA 2017-09-06 10:57:08 EDT
TODO: revert the gerrit once this bug is fixed.