Community
Participate
Working Groups
In the resolution of bug 475905, Papyrus-RT shows more consistent labels for model elements throughout the UI. In particular, the title bar of the Properties view shows the same labels as the Model Explorer and browser dialogs. However, this further highlights a usability issue in these labels, that the element icon clearly indicates the UML-RT concept and so the keyword for the stereotype from the UML-RT profile that identifies this concept is therefore redundant. So, for example, a capsule label may be rendered as [=] <<Capsule>> Hygrometer with the capsule icon and the <<Capsule>> keyword, where the keyword is redundant. It may be useful to reduce clutter and weight of text in the UI to suppress the UML-RT stereotype keywords. -------- 8< -------- Considerations ============== There are a variety of edge cases and other considerations that should be discussed in the scope of this enhancement, mostly in the realm of usability. Multiple Stereotypes -------------------- There is nothing to prevent users applying additional stereotypes to UML-RT concepts and, indeed, some common practices require this, such as code generation tags. So, for example, we can have [=] <<Capsule, CapsuleProperties>> Hygrometer with the CapsuleProperties stereotype from the C++ codegen properties profile applied. In this case, rendering a label simply as [=] <<CapsuleProperties>> Hygrometer might look misleading, suggesting that these keywords indicate the complete list of stereotypes and therefore this is not a capsule (although the icon is there). It may be better simply to show all stereotype keywords in case of multiple stereotype application. Visual Impairment ----------------- Especially on modern high-DPI monitors, it can be difficult for visually impaired users to rely on icons to distinguish the types of elements. For these users, there should be the option of retaining all stereotype keywords. State Machines -------------- The stereotypes in the UML-RT State Machines profile do not have icons; the labels present the base UML metamodel icons. However, it is generally that case that all elements in a state machine that can have an RT stereotype applied do have it applied, so keywords such as <<RTState>>, <<RTRegion>>, <<RTPseudoState>> are possibly redundant. But as there is no special icon, perhaps they should be retained? At least by default? Preferences ----------- If keywords for the core UML-RT concepts are to be suppressed, there should be a preference page for management of these labels that at least has the option to retain all stereotype keywords (to help the visually impaired). Other preferences to consider could include * how to label elements with multiple stereotypes (whether to show all keywords or not) * how to label elements that have no UML-RT-specific icon (whether to suppress the UML-RT stereotype keyword or not)
I guess this one has some relation to an old Bugzilla that I wrote on base Papyrus, Bug 462337, which proposes a mechanism with the possibility of tagging specific stereotypes to be invisible/hidden (and only possible to apply programmatically, e.g. using DSML specific tooling). This is also a mechanism which the legacy tooling have.
(In reply to Peter Cigehn from comment #1) > I guess this one has some relation to an old Bugzilla that I wrote on base > Papyrus, Bug 462337, which proposes a mechanism with the possibility of > tagging specific stereotypes to be invisible/hidden (and only possible to > apply programmatically, e.g. using DSML specific tooling). This is also a > mechanism which the legacy tooling have. Is this one then blocked on Bug 462337? Or just related ("see also") to it?
(In reply to Charles Rivet from comment #2) > (In reply to Peter Cigehn from comment #1) > > I guess this one has some relation to an old Bugzilla that I wrote on base > > Papyrus, Bug 462337, which proposes a mechanism with the possibility of > > tagging specific stereotypes to be invisible/hidden (and only possible to > > apply programmatically, e.g. using DSML specific tooling). This is also a > > mechanism which the legacy tooling have. > > Is this one then blocked on Bug 462337? Or just related ("see also") to it? I would say that it is more related ("see also") than it is blocking this one. Please add it to see also if you see it fit (I don't have the access right to do so).
