Implement message labels #251

[tortmayr]

Note: This PR reuses components which have been contributed with PR #18 for issue #16


This PR provides labels for messages which are displayed as stated in UML spec 2.5.1 (17.4.4.1). In particular it contains the following contributions:

• Editpart for Message labels
• Necessary adaptions for DiagramHelper and SemanticHelper
• LabelParser for Messages (reused from Initial Draft of Message Direct Editor #18)
• Test cases for LabelParser
• Addaptions for MessageUtil & add OperationUtil (based on Initial Draft of Message Direct Editor #18)

[planger]

Nice, thanks! I briefly tested it and it already looks very well.

A few minor changes:

• Update of operation name isn't reflected in label. To reproduce, add an operation in the signature --> Label is updated --> rename the operation --> label remains the same. Label is only updated when the name is changed or the signature object is replaced/removed itself. The same seems to be true when renaming arguments.
• Please set the font size to the size of the lifeline header label; currently it is bigger than that.
• It would be nice to avoid overflow of the label (over lifelines). I suggest to put a ... if it doesn't fit at the end of the label. Note that this will have to be automatically updated, if the lifelines are moved. Do you think that'll be easy to do?

Thanks!

[tortmayr]

I rebased this PR on the current master and added a fix for the label font size.
Additionally, I investigated the label update issue.

In the properties-view only changes made to attributes will trigger a label refresh. Changes made to references will not trigger the refresh (only if the reference is deleted or replaced)

Using the model explorer to edit the references directly will also not trigger a label refresh.
We have to register the MessageLabelEdit part as change listener for this references but I'm not sure about best way and place to achieve this.

[cdamus]

Indeed, the MessageLabelEditPart will have to behave something like a combination of EContentAdapter and ECrossReferenceAdapter: listening not only to the Message and all contained objects such as argument ValueSpecifications but also referenced objects such as the signature and, where that is a Signal or an Operation, the objects contained by that (attributes and parameters, respectively).

I'd suggest a notification-helper object alongside the MessageParser that is attached by the edit-part to the Message as an Adapter. This helper keeps track of the message's contents and its signature and the signature's contents (à la EContentAdapter) and delegates to some interface provided the edit-part to tell it about semantic elements that the edit-part needs to listen to. The parser shouldn't know about the specific MessageLabelEditPart, of course, hence the suggestion for some delegate interface that the helper can use to notify which objects a client should start or stop listening to (in the label edit-part's case via the GMF notification broker as usual).

[planger]

@cdamus Please feel free to continue with this task, if you have room for it currently. @tortmayr is currently busy with a Papyrus Compare task. He would be able to continue at the end of this week or beginning of next week.

[rschnekenbu]

I updated the PR with 2 commit: solve conflicts (trivial) and update the listener mechanism to watch model modifications and refresh semantic listeners

[rschnekenbu]

I updated message label edit parts and listeners to be notified on relevant model changes
Also, I updated the test models with some css to avoid labels being on the top of the self messages. I have hidden with css the labels to avoid such issues
There are still some evolutions required for the message labels (message wrapping for example, or placing them nicely and automatically in the diagram), but this could be handled later on a separate branch.
Could this additional commits be reviewed, @planger ?