Bug 432936 - AbstractSequenceAbsoluteBoundsFlagger.flag(ISequenceElement) does not remove the specific flags on Messages
Summary: AbstractSequenceAbsoluteBoundsFlagger.flag(ISequenceElement) does not remove ...
Status: CLOSED FIXED
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: 1.0.0M6   Edit
Hardware: PC Windows NT
: P3 normal (vote)
Target Milestone: 1.0.0M7   Edit
Assignee: Maxime Porhel CLA
QA Contact: Pierre-Charles David CLA
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-04-16 10:59 EDT by Maxime Porhel CLA
Modified: 2014-05-12 03:46 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Porhel CLA 2014-04-16 10:59:10 EDT
In some cases (changes occuring outside a Sequence editor implying reorder or creation, creation tools, complex creation tools,...), Sequence elements have their DDiagramElement flagged with several specific flags LayoutConstants.TOOL_CREATION_FLAG, LayoutConstants.TOOL_CREATION_FLAG_FROM_SEMANTIC and LayoutConstants.EXTERNAL_CHANGE_FLAG (an AbsoluteBoundFilter stored in their graphicalFilters feature).
Then the layout is able to know if the GMF bounds of an element can be trust for layout computation (in non packing layout, when the order/reparent/insertion have occured, we try to minimize the changes by conserving the previous gaps between elements or their size).
At the end of the layout, the elements are flagged with their computed bounds (then used by the layout when it needs the last known/trusted bounds).
The issue here is that, for Message we explicitely do not set the x and width because they are not used in layout (they depend on the positions of their source and target). But we have to reset the x to 0 for DEdge corresponding to Message elements.
Comment 1 Maxime Porhel CLA 2014-04-17 08:28:54 EDT
See https://git.eclipse.org/r/25181 for a fix in layout and post load auto-migration to reset the flag.
Comment 2 Maxime Porhel CLA 2014-04-18 02:31:15 EDT
Steps to reproduce on Sequence diagram
# Create two Sequence diagrams with 2 lifelines, 1 execution on each and a message from the execution to the other lifeline.
# Launch the arrange all on both diagrams
# Close one of the diagram
# Move one of the message before its execution (reconnect)
# Reopen the second diagram
# Try to move m1 up (a few pixels)

-> If the bug is present, m1 does not move but the execution and the other events below are shifted down.
Comment 3 Pierre-Charles David CLA 2014-04-24 05:04:01 EDT
Closing: the fix is merged (commit 8e0f224e7c329e0dadea121abf0a3fefb531276f), and the scenario mentioned above now works. It was not clear from the instructions, so I checked both with 2 diagrams on the same semantic model and 2 diagrams on separate models (but inside the same session). Both cases work fine now.
Comment 4 Maxime Porhel CLA 2014-05-05 02:58:54 EDT
The scenario in error was 2 diagrams on the same semantic interaction to simulate external changes dones on an interaction.
Comment 5 Pierre-Charles David CLA 2014-05-05 07:26:29 EDT
Verified on 1.0.0M7rc1 (1.0.0.20405030833).
Comment 6 Pierre-Charles David CLA 2014-05-12 03:46:11 EDT
Available in Sirius 1.0.0M7 (see https://wiki.eclipse.org/Sirius/1.0.0M7 & http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/tag/?id=v1.0.0M7).