Community
Participate
Working Groups
Created attachment 277922 [details] edgePointingToInvisibleNode.png With collapsed compartment, it is possible, in some cases, to have edge visible even if source or target is not visible. This causes to have an edge drawn from or to nowhere as in "edgePointingToInvisibleNode.png" Steps to reproduce: * Import the projet "DesignerTestProject" (from DesignerTestProject.zip): This project is a copy of data contained in "/org.eclipse.sirius.tests.junit/data/unit/compartments" but completed for this case * Open the diagram "regionWithEdges" * Collapse the "region" of "Center_p4" container (select it and click on the "-" button) * The edge from "Left_p3" and "newPackage1" disappears: OK. * Save the session * Export this diagram as png image using "Export diagram as image" button from the tabbar * Open the exported image * The edge is visible in the exported image: KO * Move the container "Left_p3" * The edge appears: KO * Move the container "Center_p4" * The edge disappears: OK This problem has been detected in Sirius 6.1.0. But it probably exists since the addition of the compartments.
Created attachment 277923 [details] DesignerTestProject.zip
Explanation for the Export as image case ---------------------------------------- In the GMF mechanism, in case of collapse of compartment, the edge is firstly "painted" and it is then hidden in asyncExec because of the the method org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeCompartmentEditPart.refreshConnections(). For example, at the diagram opening, we have this stack: Thread [main] (Suspended (breakpoint at line 614 in org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeCompartmentEditPart)) owns: org.eclipse.swt.widgets.RunnableLock (id=14479) org.eclipse.sirius.diagram.ui.internal.edit.parts.DNodeContainerViewNodeContainerCompartmentEditPart(org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeCompartmentEditPart).forceRefreshConnections() line: 614 org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeCompartmentEditPart$2.run() line: 598 org.eclipse.swt.widgets.RunnableLock.run(org.eclipse.swt.widgets.Display) line: 37 org.eclipse.ui.internal.UISynchronizer(org.eclipse.swt.widgets.Synchronizer).runAsyncMessages(boolean) line: 182 org.eclipse.swt.widgets.Display.runAsyncMessages(boolean) line: 4213 org.eclipse.swt.widgets.Display.readAndDispatch() line: 3820 org.eclipse.jface.operation.ModalContext$ModalContextThread.block() line: 165 org.eclipse.jface.operation.ModalContext.run(org.eclipse.jface.operation.IRunnableWithProgress, boolean, org.eclipse.core.runtime.IProgressMonitor, org.eclipse.swt.widgets.Display) line: 369 org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog(org.eclipse.jface.dialogs.ProgressMonitorDialog).run(boolean, boolean, org.eclipse.jface.operation.IRunnableWithProgress) line: 483 org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(boolean, boolean, org.eclipse.jface.operation.IRunnableWithProgress) line: 237 org.eclipse.ui.internal.progress.ProgressManager.run(boolean, boolean, org.eclipse.jface.operation.IRunnableWithProgress) line: 989 org.eclipse.sirius.ui.tools.internal.actions.session.OpenRepresentationsAction.run() line: 80 org.eclipse.sirius.ui.tools.internal.views.common.navigator.OpenEditorDoubleClickListener.openRepresentations(java.util.Set<org.eclipse.sirius.viewpoint.DRepresentationDescriptor>) line: 81 org.eclipse.sirius.ui.tools.internal.views.common.navigator.OpenEditorDoubleClickListener.doubleClick(org.eclipse.jface.viewers.DoubleClickEvent) line: 67 So during the opening, a readAndDispatch() is called on the UIThread to execute, among others, the refresh of the connections from the ShapeCompartmentEditPart code. But when we export the diagram as image, a new instance of the diagram is created and there is no readAndDispatch(). The edge remain visible. The fix will consist of calling readAndDispatch() before creating the image.
Explanation for the problem when the source or the target is moved ------------------------------------------------------------------ By default, GMF does not consider edges on ContainerEditPart, parent of the ShapeCompartmentEditPart, during the refreshConnections mechanism of the ShapeCompartmentEditPart (org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeCompartmentEditPart.refreshConnections()). But in Sirius, it is possible to have such. The fix will consist of considering the edges pointing to ContainerEditPart (as source or as target), parent of the ShapeCompartmentEditPart, in the refreshConnections mechanism.
New Gerrit change created: https://git.eclipse.org/r/139043
New Gerrit change created: https://git.eclipse.org/r/139042
New Gerrit change created: https://git.eclipse.org/r/139044
New Gerrit change created: https://git.eclipse.org/r/139093
Gerrit change https://git.eclipse.org/r/139042 was merged to [v6.1.x]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=cd795c7dd938845a337fa9c9576ee05a29a88aa1
Gerrit change https://git.eclipse.org/r/139044 was merged to [v6.1.x]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=084686eb6c15c106ef2c8c4bc78041a7fe8ff86d
Gerrit change https://git.eclipse.org/r/139093 was merged to [v6.1.x]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e17bb08c03b956e6d9d0c3da0a330a37a9e894c9
Gerrit change https://git.eclipse.org/r/139043 was merged to [v6.1.x]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=b4cb16ea16567db32567e07f522db5377baca398
Steps to validate: * All "steps to reproduce" from the description must be OK.
Validated with T4C 1.3.1 it5
Available in Sirius 6.1.3, see https://wiki.eclipse.org/Sirius/6.1.3
