Community
Participate
Working Groups
Build Identifier: 20110916-0149 As today (Graphiti 0.8 - 0.9) the core plugins define many extensions that "pollute" the Eclipse UI. Typical scenario: I'm use the Graphiti framework for developing my own RCP application, I want to use the core plugins untouched (by 'core plugins' I mean the plugins that provide Graphiti infrastructure, excluding tutorial and test related) , and I will code my own plugins, using/extending Graphiti plugins, and defining his own perspectives, editor, menus, etc. In my final RCP application, I don't want the user to see a "Graphiti perspective", for example. And, as it's known, in Eclipse is easy to add extensions, but difficult to disable them. I propose hence to move all these potentially invasive extensions (views, perspectives, menus, key bindings, editors) to the examples.* plugins, which should be regarded as template source for the user own plugin. Reproducible: Always
There is an graphiti.ui plugin which contains the UI relevant FRAMEWORK parts. If you say you want to remove the Graphiti perspective from the ui plugin i can understand that (a little bit), but the editor?? That is an integral part of the framework. Why should it reside in an example plug-in? Also key bindings etc should not differ across several Graphiti adopters. We want a homogeneous eclipse user experience. The same counts for menus, views etc. For this bug there should be a clear description which elements should be moved from where to where and why. Please clarify. If we would restructure the code as you hinted at, that would be a major API breakage. There need to be very good reasons.
This is a list of all extensions provided by the Graphiti framework: Plugin org.eclipse.graphiti.mm Extension Point org.eclipse.emf.ecore.generated_package graphiti/mm graphiti/mm/pictograms graphiti/mm/algorithms graphiti/mm/algorithms/styles Plugin org.eclipse.graphiti Extension Point org.eclipse.core.runtime.preferences org.eclipse.graphiti.internal.pref.PreferenceInitializer Plugin org.eclipse.graphiti.ui Extension Point org.eclipse.ui.views org.eclipse.graphiti.ui.internal.editor.thumbnailview category org.eclipse.graphiti.ui.Graphiti_Category Extension Point org.eclipse.ui.editors org.eclipse.graphiti.ui.editor.DiagramEditor Extension Point org.eclipse.core.contenttype.contentTypes org.eclipse.graphiti.content.diagram Extension Point org.eclipse.ui.elementFactories org.eclipse.graphiti.ui.editor.DiagramEditorInputFactory Extension Point org.eclipse.graphiti.ui.imageProviders org.eclipse.graphiti.ui.platform.PlatformImageProvider Extension Point org.eclipse.ui.commands category org.eclipse.graphiti.ui.Graphiti_Category org.eclipse.graphiti.ui.internal.action.UpdateAction org.eclipse.graphiti.ui.internal.action.RemoveAction org.eclipse.graphiti.ui.internal.action.SaveImageAction Extension Point org.eclipse.ui.bindings org.eclipse.graphiti.ui.internal.action.UpdateAction org.eclipse.graphiti.ui.internal.action.RemoveAction org.eclipse.graphiti.ui.internal.action.SaveImageAction So, I don't see any perspectives defined here. There's one in the examples.common plugin and in the tests, but these plugins should not be installed into an RCP. Regarding the UI extensions, I aggree with Tim in that the editor, the factory, the commands and key bindings should be controbuted by the framework in order to have this homogenously accross all editors. Also the Graphiti image provider should be here, but that does not reflect in the UI anyway... The only thing I wonder if they should appear here are the view and its category?
I'm closing this as there is no activity for 2 months now. If you would like to continue on this, feel free to re-open.
