Community
Participate
Working Groups
As an Eclipse add-in Provider (and an original Eclipse member), we are building products based on Eclipse (with EMF & GEF) and don't want to (nor can we) use the Rich Client "ground-up" approach to building these apps. The reason is, we want our products to easily take full advantage of the Eclipse UI and services (without unwanted functionality that doesn't apply to our product and confuses our users); but, we would like to allow some of our more advanced users to turn on this other Eclipse functionality (through the Activities architecture) to the degree that they want - so, they could introduce back in the ability to use Java tools, Ant tools, build etc. that they can use side-by-side with our tools. But, by default, we want these all turned off and just have a basic set of menus, preferences, etc. that would make sense for any general application. The big problem we're having is there are several elements that show up in the Eclipse UI (menus, help, toolbar, preferences, keyboard bindings) that don't make sense for a general product. Eclipse makes too many assumptions about base UI, that all really should be contributed via plug-ins rather than being hard-wired in. This is a really big problem and a difficult architecture to build apps on. You cannot assume that every Eclipse-based app is going to be a Java-like development/build environment. We would like to build products on Eclipse that don't have these metaphors. Yet these types of applications, still would share most of the UI and capabilities that Eclipse provides as the "base" experience. Eclipse is very close (most of the UI and contributions make sense and would be a great base for any product), but it's not close enough to really be able to build a wide range of real-world apps on, without great effort and hacks. With just a little more adjustments, it would be all be fine and great. I've talked to many key Eclipse engineers about this face to face at the last Eclipse conference in Anaheim (I can't remember all of their names, but I remember discussing this with Todd Creasey and John Weigland and a few others), and they all agreed it was a problem and that too many things are still hard-wired in and should be contributed in a plug-in. They said this couldn't be done in 3.0, but could conceivably be possible in the 3.1 time frame. In the meantime, we are having to jump through very painful re-packaging hoops to have the user experience we want with Eclipse. The following lists the adjustments we have to make. With these adjustments, we are happy, except that we now have no way of ever being able to turn the "lost" functionality back on; so, we are crippled from how we want the experience to ultimately be. So, we beg you to allow us to do this the right way rather than this short-sighted "hack" way that we are forced to do currently. The following details the 4 major areas we have to re-package: #1. We have to go into the following plug-ins and remove all of their extensions (we can't remove the whole plug-ins, because we need them for functionality, we just don't want them to surface "extra UI contributions" that don't make sense in our product): org.eclipse.ant.core org.eclipse.ant.ui org.eclipse.compare org.eclipse.debug.ui org.eclipse.debug.core org.eclipse.emf.codegen.ecore org.eclipse.emf.codegen.ui org.eclipse.emf.codegen org.eclipse.emf.codegen.ecore.ui org.eclipse.emf.common.ui org.eclipse.emf.commonj.sdo org.eclipse.emf.mapping.ecore2ecore.editor org.eclipse.emf.ecore.edit org.eclipse.emf.ecore.editor_ org.eclipse.emf.ecore.sdo org.eclipse.emf.ecore.sdo.doc org.eclipse.emf.ecore.sdo.editor org.eclipse.emf.ecore.sdo.edit_ org.eclipse.emf.ecore.sdo.source org.eclipse.emf.edit.ui org.eclipse.emf.mapping.ui org.eclipse.emf.mapping.xsd2ecore org.eclipse.emf.mapping.xsd2ecore.editor org.eclipse.jdt.debug.ui org.eclipse.jdt.ui; org.eclipse.jdt.debug org.eclipse.jdt.core org.eclipse.jdt org.eclipse.jdt.source org.eclipse.jdt.junit.runtime org.eclipse.jdt.launching org.eclipse.jdt.doc.isv org.eclipse.jdt.junit org.eclipse.jdt.doc.user org.eclipse.ltk.ui.refactoring org.eclipse.ltk.core.refactoring org.eclipse.search org.eclipse.team.cvs.ui org.eclipse.team.cvs.core org.eclipse.team.ui org.eclipse.team.core org.eclipse.ui.externaltools org.eclipse.ui.presentations.r21 org.eclipse.ui.cheatsheets org.eclipse.xsd.doc org.eclipse.xsd org.eclipse.xsd.edit org.eclipse.xsd.source org.eclipse.xsd.editor org.eclipse.xsd.test org.eclipse.pde org.eclipse.pde.core org.eclipse.pde.ui org.eclipse.pde.junit.runtime org.eclipse.pde.build #2: We have to remove the toc.xml files from the following plug-ins: org.eclipse.pde.doc.user org.eclipse.jdt.doc.user org.eclipse.jdt.doc.isv org.eclipse.pde.ui_x.x.x/templates_3.0/help org.eclipse.pde.ui_x.x.x/templates/help org.eclipse.platform.doc.user org.eclipse.platform.doc.isv org.eclipse.xsd.doc org.eclipse.emf.ecore.sdo.doc org.eclipse.emf.doc org.eclipse.draw2d.doc.isv org.eclipse.gef.doc.isv #3. We do surgical editing of the plugin.xml for org.eclipse.ui.editors Description Basic text editor “editor” and menu items (open external file), etc. Removed Items File|Open Untitled Text File menu item <actionSet label="%newTextEditorActionSet.label" visible="true" id="org.eclipse.ui.edit.text.actionSet.newTextEditor"> <action definitionId="org.eclipse.ui.edit.text.newTextEditor" label="%newTextEditor.label" helpContextId="new_text_editor_action_context" class="org.eclipse.ui.internal.editors.text.NewTextEditorAction" tooltip="%newTextEditor.description" menubarPath="file/new.ext" id="org.eclipse.ui.edit.text.newTextEditor"> </action> </actionSet> Plugin org.eclipse.ui.ide Description Basic UI functionality. This includes the application, perspectives, wizards, views, preference pages and menu items. Removed Items New Project Wizard under the Simple category <wizard name="%NewWizards.project" icon="icons/full/etool16/newprj_wiz.gif" category="org.eclipse.ui.Basic" class="org.eclipse.ui.wizards.newresource.BasicNewProjectResourceWizard" project="true" id="org.eclipse.ui.wizards.new.project"> <description> %NewWizards.project.description </description> </wizard> Build Order preference page <page name="%PreferencePages.BuildOrder" class="org.eclipse.ui.internal.ide.dialogs.BuildOrderPreferencePage" id="org.eclipse.ui.preferencePages.BuildOrder"> </page> Workbench|Label Decorations preference page <page name="%PreferencePages.Decorators" category="org.eclipse.ui.preferencePages.Workbench" class="org.eclipse.ui.internal.dialogs.DecoratorsPreferencePage" id="org.eclipse.ui.preferencePages.Decorators"> </page> Workbench|Linked Resources preference page <page name="%PreferencePages.LinkedResources" category="org.eclipse.ui.preferencePages.Workbench" class="org.eclipse.ui.internal.ide.dialogs.LinkedResourcesPreferencePage" id="org.eclipse.ui.preferencePages.LinkedResources"> </page> Problem View <view name="%Views.Problem" icon="icons/full/eview16/problems_view.gif" category="org.eclipse.ui" class="org.eclipse.ui.views.markers.internal.ProblemView" id="org.eclipse.ui.views.ProblemView"> </view> Build All key binding <keyBinding commandId="org.eclipse.ui.project.buildAll" platform="carbon" keySequence="Command+B" keyConfigurationId="org.eclipse.ui.defaultAcceleratorConfiguration"> </keyBinding> Plugin org.eclipse.ui Description Basic extension points (actionSets, popupMenus, perspectives, etc.) Basic editor actions (cut, copy, paste, etc.), key bindings and other items. Removed Items Next and Previous key bindings <keyBinding commandId="org.eclipse.ui.navigate.next" keySequence="Ctrl+." keyConfigurationId="org.eclipse.ui.defaultAcceleratorConfiguration"> </keyBinding> <keyBinding commandId="org.eclipse.ui.navigate.previous" keySequence="Ctrl+," keyConfigurationId="org.eclipse.ui.defaultAcceleratorConfiguration"> </keyBinding> Plugin org.eclipse.gef Description Zoom in and out commands and key bindings. Removed Items Palette view <extension point="org.eclipse.ui.views"> <view name="%Palette.Label" icon="icons\palette_view.gif" category="org.eclipse.ui" class="org.eclipse.gef.ui.views.palette.PaletteView" id="org.eclipse.gef.ui.palette_view"> </view> </extension> 4. We made dynamic changes to the Eclipse UI (outside in, without modifying source code) at runtime by doing the following: Class org.eclipse.ui.internal.ide.WorkbenchActionBuilder Change Remove the following menu items when our product's perspective is active: File|Revert Navigate|Next Navigate|Previous Project|Open Project Project|Close Project Project|Build All Project|Build Project Project|Build Working Set Project|Clean... Project|Build Automatically Class org.eclipse.ui.internal.ide.dialogs.IDEWorkbenchPreferencePage Change Remove the following checkboxes from the Workbench preference page: Always run in background Build automatically Refresh workspace automatically Save automatically before build Keep next/previous part dialog open This all seems like a lot, but I believe a little bit of changes in the right places architecturally in the product, would relieve a huge burden off of people like us that are trying to write more general apps on the Eclipse framework. Please strongly consider implementing these changes. We believe it would be beneficial for the entire community and architecture going forward. Any improvement in this area would be really helpful. Thanks!
Lee, Thanks, this is useful feedback, and sorry for the delay in responding. We are, however, aware of these kinds of issues overall and agree they are one of the major stumbling blocks in the adoption of RCP. See bug 73587 for some progress we've made in 3.1 on enabling the kind of separation of functionality from presentation that you describe here. The factories approach has its own set of problems though, e.g. requiring separate plug-ins for the presentation extensions. > Please strongly consider implementing these changes. Can you be more specific about which changes you think we should apply? You have described the extensions that you've had to go and manually hack out. Obviously we can't just go and do the same, or we would break the IDE. Do you have any concrete suggestions for improved mechanisms, or better factoring, that could help? We could add some hackoid mechanism like "ignore all UI contributions from plugins X, Y, Z". But that would only apply for workbench extensions, and wouldn't address the finer-grained changes you describe. When you say you remove all extensions, do you mean -all- extensions, or just extensions to the workbench (views, pref pages, action sets, etc). E.g. would you remove the Java builder from JDT core? Finer grained control over what appears in preference pages is an interesting problem. Right now the granularity of contribution is a single page, but it would be interesting to consider contributing invidual preferences or sections, and having the pages be aggregated from these. There would still be the problem of product-specific filtering though. In bug 73587, I summarized an idea from Dorian Birsan about using something like J2EE deployment descriptors to override the default extensions provided by reusable component plug-ins. Do you have any experience with this mechanism, and do you think it's potentially applicable?
Thanks for the response. Bug #73587 didn't answer directly our request, but embedded in it are some ideas that can help in this space. But, I want to be clear, we do not want to write any additional extensions, provide custom UI, etc. to solve this problem. And, we're also not interested in using J2EE deployment descriptors to override default extensions. Again, we're not trying to override UI, we just want the option to turn off certain UI and either turn it back on, or contribute our own UI in its place. We would like, out of the box, certain "UI" elements in core Eclipse to be moved out into a separate plug-in so that the UI can be turned off with the Capabilities architecture, but still have the underlying functionality and services of the plug-in available underneath. We then would allow our more advanced users to turn that UI on back on, if they choose. It seems like elements 73587 can conceivably go in a direction that would help you facilitate providing this. Again, our premise is, we're trying to build Eclipse-based applications, none of which, have the concepts of "build", "java", "ant", "cvs", etc. so we don't want any of those "assumptions" in the UI - it's not appropriate for our users. And, here's the catch, we really can't build our apps from scratch with RCP because we want most of what's there in core Eclipse and we'd like users to be able to turn on the "build", "java", "ant", "cvs', and other UI of core Eclipse elements if they so choose. I would imagine many other companies would have this very same need. Specifically, we would like the following UI elements to be able to be turned off: New Project: 1) Java Project 2) Plug-in Project 3) Eclipse Modeling Framework - we need EMF for our app to run, be we don't want our users exposed to any EMF UI directly (I think work being done in 73587 might help here, but we're talking about allowing this all to be turned on/off through the Capabilities architecture) 4) GEF - same thing 5) Java Folder 6) Solutions Project Menu: 1) Build All 2) Build Project 3) Build Working Set 4) Clean 5) Build Automatically 6) Generate Javadoc Remove "Search" menu. This makes assumptions that you are always searching Files, Java elements, or Plug-ins. Our product, also has the concept of searching, but we want to allow for different types of searches; so, if we can turn off the "base" search and then contribute out own, we would be happy. We would also like to hook the "Find and Replace" on the Edit Menu so it can contextually bring up the appropriate UI based on the editor - the default UI, or our own custom UI. Turn off any other Perspective or View, other than the ones that we contribute, besides the "Basic" views and "PDE Runtime" (because they’re pretty core and useful for most apps). All of the other "built-in" ones that come with Eclipse have no meaning to our customers: Java, Plug-ins, CVS, Team, Plug-ins, Ant, Turn off the following Preferences pages: 1) General -> Compare/Patch 2) General -> Startup and Shutdown (we have no notion of refresh, etc.) 3) Ant 4) Build Order 5) Java 6) Plug-in Development 7) Run/Debug 8) Team It's intriguing to consider the possibility of turning off "parts" of a preference page, but not really necessary. For the most part, just being able to turn off an entirely "unneeded" page is sufficient. We would also like to be able to turn off the "Help", "Cheat Sheets", and "Tips & Tricks" of all plug-ins, except for the ones we contribute. In all of this, we would not want the Key Bindings for these "removed" elements to appear in any UI or list. Also, the commands should not show up in areas, such as in the Perspective customization dialog. This is really all we need and this would make us very happy. As you can see, we're not asking for a new fancy architecture, just that some "core hard-coded" UI assumptions be contributed separately in plug-in so they be turned off. You can see that most of the UI of Eclipse is retained and most of the other UI assumptions remain valid for most apps - since, most apps will need a File menu with Save, Close, Undo, Redo, Help, Window management, cut, copy, paste, etc. In the future, you might even allow for moving more of core UI into separate plug-ins, but following the 80/20 rule, you will get diminishing returns at some point. I believe the above proposal ought to be a decent standard for most companies, architectures, and use cases. Thanks!
Reassigning bugs in component areas that are changing ownership.
You can now "turn off" declarative contributions (by the way: not only to the UI, and not only turning off, but also modifying). See the plan item (bug 154099) and the corresponding wiki page at: http://wiki.eclipse.org/index.php/Product_Customization Quoting from the bottom of the wiki page: This solution has been implemented and now resides in the Equinox Incubator in the projects that start with org.eclipse.equinox.transform.
Prakash is now responsible for watching bugs in the [RCP] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
