Bugzilla – Full Text Bug Listing
| Summary: | [General] Diagram creation commands should not be visible when they do not support the model language | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Yann Tanguy <yann.tanguy> |
| Component: | Core | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cletavernier, laurent.wouters, vincent.hemery |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 354791 | ||
|
Description
Yann Tanguy
Done in r2522:
- Action provider for diagram creation removed from model explorer, and replaced by a simple ui.menu (popup)
- All diagrams now contribute a creation command in the Model Explorer ("New Diagram" menu), this command is the same as the creation command used in main menu and toolbar.
- Diagram creation command visibility is homogeneously set
- Property testers have been defined to test the nature of the model (SysML, UML Model, and UML Profile currently)
- Reusable test definition have been created in o.e.p.diagram.common and o.e.p.sysml.diagram.common and supposed to be reused by diagrams as command visibility tester
To be completed:
- SysML tester currently test the root element and check the SysML root profile application. It should also test that all SysML subprofiles are available
- Additional selection based constraint can possibly be added to modify the command enablement (the visibility should not be modified on selection as this tends to generate confusion about which diagram are really available)
Possibly deprecated and unused classes:
- CreateChildActionProvider (o.e.p.modelexplorer) -> now uses the UML service creation and ui.commands
- CreateDiagramActionProvider -> now uses the diagram creation command directly specified with the ui.command framework
- The PapyrusDiagram extension point is still used for diagram creation from wizards but may possibly be simplified (in particular, not sure that the creation constraint is still useful)
Some action providers (for diagram creation, child element creation) have been marked deprecated. Additional test to ensure Papyrus is the current active editor before testing model nature. (In reply to comment #1) > Done in r2522: > > - Action provider for diagram creation removed from model explorer, and replaced > by a simple ui.menu (popup) > - All diagrams now contribute a creation command in the Model Explorer ("New > Diagram" menu), this command is the same as the creation command used in main > menu and toolbar. > - Diagram creation command visibility is homogeneously set > - Property testers have been defined to test the nature of the model (SysML, UML > Model, and UML Profile currently) > - Reusable test definition have been created in o.e.p.diagram.common and > o.e.p.sysml.diagram.common and supposed to be reused by diagrams as command > visibility tester > > To be completed: > - SysML tester currently test the root element and check the SysML root profile > application. It should also test that all SysML subprofiles are available > - Additional selection based constraint can possibly be added to modify the > command enablement (the visibility should not be modified on selection as this > tends to generate confusion about which diagram are really available) > > Possibly deprecated and unused classes: > - CreateChildActionProvider (o.e.p.modelexplorer) -> now uses the UML service > creation and ui.commands > - CreateDiagramActionProvider -> now uses the diagram creation command directly > specified with the ui.command framework > - The PapyrusDiagram extension point is still used for diagram creation from > wizards but may possibly be simplified (in particular, not sure that the > creation constraint is still useful) in r2578 Erroneous command id (due to previous changes) in sequence diagram which resulted in an Activity diagram being created in place of Sequence diagram (when using the Model explorer context menu). Fixed in r2585. In 2996: printstackTrace -> log (In reply to comment #1) > - Property testers have been defined to test the nature of the model (SysML, > UML Model, and UML Profile currently) I disagree with current implementations of PropertyTester : org.eclipse.papyrus.diagram.common.util.UMLSelectionTester.testUMLModelNature(Object) org.eclipse.papyrus.diagram.common.util.UMLSelectionTester.testUMLProfileNature(Object) org.eclipse.papyrus.sysml.diagram.common.utils.SysMLSelectionTester.testSysMLModelNature(Object) I think testing the root of the model is just wrong. Moreover, testing that the root is a 'Model' object for UML causes a blocking bug for controlled resources, since their root is a 'Package'. I think we should better recover the selected element, like in org.eclipse.papyrus.core.adaptor.gmf.AbstractPapyrusGmfCreateDiagramCommandHandler.getSelectedElement(), then run a specific test on it : - testUMLModelNature : that it is a org.eclipse.uml2.uml.Element - testUMLProfileNature : that it is a org.eclipse.uml2.uml.Profile - testSysMLModelNature : that it is a org.eclipse.uml2.uml.Package with SysML profile applied (may be inherited from parent application) Of course, that would mean you can draw a UML diagram (like class) under a profile, or that you can draw a Profile diagram in a Profile which is under a Package in a UML model. Though it is in accordance with UML specification, this may be give too many possibilities for the end user. Maybe we could make a preference to restrict it a little more to make the UML and Profile cases exclusive (more like now). The point I'm a bit afraid of, is that since it depends on the selected element, the toolbar will change depending on the selection, which can make the user a bit confused. But after all, isn't that what we really want ? Please, tell me your opinion on these points. In the meantime, I will at least enable UML diagrams for controlled resources (enabled for roots which are Packages but not Profile, instead of Model in current implementation). Enable UML diagrams for controlled resources : on trunk in r5201 on 0.8.X branch in r5202 I share your concern but I can't see a perfect solution for this. We tried your proposal at the beginning of Papyrus MDT (I mean toolbar diagram buttons status changing with the current selection) and this was very distracting for users. As a general usability concern it is probably better to open the discussion (forum or mailing list) and try to gather some expectations regarding the desired behavior for this. An acceptable solution might be to have a simplified toolbar to avoid the flashing toolbar (i.e. only show SysML Diagrams for a SysML root model), and have a more precise context menu, activated on each compatible element (i.e. SysML Packages, even when the root model is not SysML) This is fixed in Luna post M6 in commit f515b310417b386c79d9fbd2500c5373a7179aa7 with creation command selectively displayed by the applied viewpoint and active policy. > This is fixed in Luna post M6 in commit f515b31
I close the task
|