[mdt-papyrus.dev] About stereotype display as comments on diagram (Stere

[Alain Le Guennec <Alain.LeGuennec@xxxxxxxxxxxxxxxxxxxxxxxx>]

Hi,

After migration to Papyrus 1.1, we noticed that management of stereotype display as comments on diagrams was completely overhauled.

We have a few concerns/issues about the new implementation,

that we would like to raise before filling-in new bugzilla entries if necessary:

-We noticed that, from now on, if an element has a stereotype applied,

 whenever a new view is created for that element (say a stereotyped class, eg a <<metaclass>>),

 an accompanying "StereotypeComment" shape and "StereotypeCommentLink" edge are created.

 This is also done when opening an old 1.0 diagram with Papyrus 1.1

 (as this is actually implemented by the AppliedStereotypeCommentEditPolicy, upon activation).

-Even if created invisible, those shapes and edges are *persisted* views,

 which adds quite a lot to the .notation of existing meta-model diagrams, for nothing new displayed

 (one can see those shapes and edges if opening the model back with Papyrus 1.0, as invalid views).

-Is the fact that those views are created unconditionally

 (and not "on-demand" when the user wants to display stereotypes as comments) intentional?

 Wouldn't it make more sense to create them on-demand, lazily?

-After review of the new code that handles all this, it turns out that it makes extensive use of GMFUnsafe.write(),

 so that the creation of the invisible comment shapes and edges is not visible on the undo-stack itself.

 Those calls to GMFUnsafe.write() are called from outside any command by the edit policy.

 The thing is, this seems to cause all sorts of troubles with undo/redo.

 We have noticed at least two different symptoms:

 -After a "delete from diagram" of a meta-class view, then undo, sometimes only the StereotypeCommentLink edge is back, not the StereotypeComment shape, and the link has a null target..

  No need to say, this seriously confuses the section of the "Appearance" property tab that normally allows to make stereotype applications visible as comments (lots of exception are raised).

 -Undo of "delete from diagram" in case of multi-selection of many meta-class views often fails "in the middle" with a RollBack exception,

  presumably because the the list of nodes/edges of the diagrams was modified "under the hood" between the time the command was created then undone,

  restoring only part of the views but not all of them.

org.eclipse.core.commands.ExecutionException: Undo of operation was rolled back (possibly due to concurrent write)

at org.eclipse.emf.workspace.AbstractEMFOperation.undo(AbstractEMFOperation.java:409)

at org.eclipse.gmf.runtime.diagram.ui.commands.ICommandProxy.undo(ICommandProxy.java:94)

at org.eclipse.gef.commands.CompoundCommand.undo(CompoundCommand.java:191)

at org.eclipse.gef.commands.CompoundCommand.undo(CompoundCommand.java:191)

at org.eclipse.papyrus.commands.wrappers.GEFtoEMFCommandWrapper.undo(GEFtoEMFCommandWrapper.java:121)

at org.eclipse.emf.workspace.EMFCommandOperation.doUndo(EMFCommandOperation.java:153)

at org.eclipse.emf.workspace.AbstractEMFOperation.undo(AbstractEMFOperation.java:370)

at org.eclipse.core.commands.operations.DefaultOperationHistory.doUndo(DefaultOperationHistory.java:420)

at org.eclipse.core.commands.operations.DefaultOperationHistory.undo(DefaultOperationHistory.java:1255)

at org.eclipse.ui.operations.UndoActionHandler.runCommand(UndoActionHandler.java:87)

 

This is making diagram editing feel not as robust as before.

Personally, I would feel much more confortable if the comment shape and edge were added only on-demand,

as part of the command that modifies the corresponding appearance property. 

Any comment on this is most welcome!

--

Alain Le Guennec, R&D Expert Engineer

SCADE System Project Manager

Esterel Technologies, a wholly-owned subsidiary of ANSYS, Inc.