Community
Participate
Working Groups
During Bug 434474 correction, it appears that Sirius could restrict several extensions : . org.eclipse.gmf.runtime.diagram.ui.editpolicyProviders: . DoubleClickEditPolicyProvider uses the provide(IOperation) method to indicate the scope of the provider: OK . ChangeBoundRequestRecorderEditPolicyProvider does several checks in the createEditPolicies(EditPart) methods, some of these should be done in the provide(IOperation) method. . We should check if it is relevant here to use the Object and the context elements in the plugin.xml . org.eclipse.gmf.runtime.diagram.ui.editpartProviders: . SiriusEditPartProvider checks in the provides(IOperation) method that the current diagram have the expected Sirius type. . We should check if it is relevant here to use the Object and the context elements in the plugin.xml . org.eclipse.gmf.runtime.diagram.ui.viewProviders: . the element types and diagram type are used to check if the SiriusViewProvider has a class to create the expected view. . the diagram context uses the semanticHint: the SiriusViewProvider is only used to populate the diagram direct children in case of Sirius diagram. . We should check if it is relevant here to to improve the declared Context and use some Object to improve clarify the declaration. (On the first read, I thought we could provide our views to toher GMF editors, but in fact the elementType checks avoid this). The use of more complete contexts could avoid our providers to be called for nothing in other GMF editor. From my understanding, our providers are written to provide only elements in Sirius Diagram editors, even if they they can be called from other editors and they will return/create nothing.
