Community
Participate
Working Groups
An additional page in the initialization wizard can allow the selection of the elements that should appear in the initialized diagram.
To solve this enhancement I need to know whether the 'org.eclipse.papyrus.core' plugin can depend on GMF. I think the plan was to make it independent from GMF. What will be done finally regarding the GMF dependency- Cedric, it would be great if you could throw som light into this issue.
The core itself should be independant from GMF. But, there is another plugin (org.eclipse.papyrus.editor) build upon the core and allowing to put the dependencies on GMF, if required. But, the elements that should appears in a diagram are linked to this diagram. So, why do not put the definition of the page and of the available elements in the plugin of the diagram, in the same placeas the diagram definition ?
Now the 'org.eclipse.papyrus.core' has dependencies with the 'org.eclipse.gmf.runtimw.diagra.ui' plugin. The implementation of this feature can be placed in the 'org.eclipse.papyrus.wizards' plugin which would not affect the core plugin, only that there are some util methods that coulb be placed in the core plugin on in the wizards plugin. As I see that the plan is making the core plugin GMF independent I will place the methods in the wizards plugin. As for the diagram initialization with selected elements, I agree that each diagram definition should provide which elements are available in it but there can be a general part too. The general part is already prepared. Now for the specific part of each diagram the generation templates can be modified so that each diagram can provide information about the views it can contain. Patrick, what do you think about modifying the generation templates to include this funciontality? It has already been done in MOSKitt and only a porting would be required.
I'm not convinced to modify generation templates is a good solution. I think that it exist no a generic solution that can be solved by code generation: + i think that the diagram initialization can be different for each diagram. + moreover some element are very specific, and need custom code for example multiassociation multidependencies and association for class diagram -> I have had this problem for the drag and drop so I have created a generic class that contains a hook filled by subclasses. for the drag and drop I have added only a specific editpolicy in the gen model for the initialization maybe , it can be the case no? this solution is very interesting because it avoid to modify templates. if you have to modify templates, which modifications are? it is numerous? (bugs on drag and drop see 282390: [General]Drop of links does not run https://bugs.eclipse.org/bugs/show_bug.cgi?id=282390)
I think that the drag&drop solution can be used to initialize the views when a new diagram is created form an existing model. It needs to be made available from outside the plugin so that the wizard can create the views using that solution. Maybe an extension point could provide the drag&drop view creation mechanism and that extension point be used by the wizard. Patrick, do you think this could be done?
postponed to next version 0.8.0.
