Description Pierre-Charles David 2017-01-18 10:38:07 EST

The labels currently used for most VSM elements are relatively poor in terms of information presented. This leads to a lot of clicking around to see the useful information: select the element in the editor, then find the property you're interested in in the property view, possible by selecting a different tab.

Without going overboard, it should be possible to increase the "information density" and make more information directly visible in the editor, without needing to "dig into the properties view". Some candidate for information that could be "pulled up" in the labels:
* domain classes for representation descriptions and mappings;
* semantic candidate expressions for mappings (these can be long, so some kind of limit should be put on the label size);
* label expression for styles;
* maybe some markers for special/unusual properties (e.g. "Unsynchronized" mappings).

These are just ideas, not to be taken as a spec of what will be done in the end.

Some aspects to take into account:
* a typical use case for a specifier is to have both the VSM and a sample representation opened at the same time along each other. We should avoid making the labels so long that they are not entirely visible in such a "split layout";
* since for Sirus 5.0 we'll drop support for Eclipse versions before Neon, we can assume the presence of a recent version of EMF, and if we deem it useful we can make use of IItemStyledLabelProvider (introduced in EMF 2.10) to put some style on our labels. This may become necessary to keep them easily parsable as we add more information to them.