| Summary: | [All diagrams] Display applied stereotype on class in diagram | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Toni Siljamäki <toni.siljamaki> |
| Component: | Diagram | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Celine.janssens, cletavernier, laurent.wouters, papyrus-bugs, rschnekenburger |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 457024 | ||
|
Description
Toni Siljamäki
Historically, we did not want to have any guess on what Papyrus shall display or not on elements. That is why dropped classes do not display properties, operations and applied stereotypes, but it can be a pain to select the display of applied stereotypes. For the content of the compartiment, a dialog displays the list of available properties/operation, etc, but there is no way to display stereotypes easily. - It should be possible to provide a specific drop for stereotyped elements, based on the customizable drop framework in Papyrus. Thus it could be selected/unselected in the preferences. - Another solution could be the use of CSS to handle stereotype display. Toni, would you prefer it to be done specifically for classes or for all elements in class diagram? What a user expect, I think, is that the stereotype info displayed in the Model Explorer should also be displayed in the diagram, such as for classes, class operations, activity nodes etc., both when they are created in the diagram and when drag-and-dropped into it. The applied stereotype info for an element is just as important as the name of the element, both in Model Explorer and in a diagram. Another way of looking at this is: Why display stereotype info by default in Model Explorer but _not_ in the diagram? This is fixed in a25fb2153a8f54f539f8508d4081aba794ba8733 with CSS properties: displayStereotypes: true; // force display stereotypes This one is not fixed. Testing Papyrus UML 1.1.0.201504081422 This should be fixed in Mars release 1.1 |