Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 432936

Summary:	AbstractSequenceAbsoluteBoundsFlagger.flag(ISequenceElement) does not remove the specific flags on Messages
Product:	[Modeling] Sirius	Reporter:	Maxime Porhel <maxime.porhel>
Component:	Diagram	Assignee:	Maxime Porhel <maxime.porhel>
Status:	CLOSED FIXED	QA Contact:	Pierre-Charles David <pierre-charles.david>
Severity:	normal
Priority:	P3	CC:	pierre-charles.david
Version:	1.0.0M6	Keywords:	triaged
Target Milestone:	1.0.0M7
Hardware:	PC
OS:	Windows NT
Whiteboard:

Description Maxime Porhel

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

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

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

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

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

2014-05-05 07:26:29 EDT

Verified on 1.0.0M7rc1 (1.0.0.20405030833).

Comment 6 Pierre-Charles David

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).