Summary: | [RCP] Need Better Stripping | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Lee Lowry <llowry> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | cpuidle, eclipse, jeffmcaffer, tom.seidel |
Version: | 3.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: | incubator |
Description
Lee Lowry
2004-12-27 10:27:38 EST
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. |