Eclipse 4.0/Wishlist

This page is obsolete
Eclipse 4.0 development concluded in July 2010. See Eclipse4 for details.

This page lists things people would like to see addressed/fixed in Eclipse 4.0. Some of the items in this list were originally posted as comments on https://bugs.eclipse.org/bugs/show_bug.cgi?id=200097.

• I'd like to have the modern container features like ioc in equinox for Eclipse 4. One example I can think of is injecting configurations into plugin, configuration by annotation. For extension points, maybe we can borrow some things in Tapestry 5 (http://tapestry.apache.org/tapestry5/tapestry-ioc/). --John Willson See bug 209873 for experimental work in this direction (for Platform UI and the Workbench). --Boris Bokowski
• Create an Eclipse 3.6 to perform Usability testing to see what parts of eclipse are actually used. We can grab a lot of data from this so developers know.
• Syntax highlighting. Modernize it to something like Textmate or vim. Also, don't separate syntax highlighting all across the preferences. WTF?
• In general, simplify the UI so it makes sense. People literally have to "Filter search" for the setting they want to change. This is an example of awful UI design. It defeats the purpose of having an IDE in the first place.
• Considering have the Eclipse association hire or find a pro bono UI developer who can lead an effort to modernize the UI
• Fundamentally Eclipse is doing great but 2 big areas I think the community would love to see get attention in the next major version is the concept of workspaces and the resources in them. The WorkspaceRoot should be able to contain other workspaces and not just projects. Currently dealing with multiple projects with the same name (a project from the trunk and a branch) is cumbersome because multiple workspaces are needed. In this case multiple workspaces are still needed but are contained, from a model standpoint not necessarily physically, within a single root. And finally nested projects, the next major version simply needs to support them. As an example to hopefully make this clearer, if a user is working on 2 streams of development for Product Foo and another Product Bar then the Eclipse workspace model with look like: --Binyan

WorkspaceRoot/
  Product Foo [trunk]       <- is a workspace
    Project A
    Project B
    Project C
  Product Foo [3.x branch]  <- is a workspace
    Project A
    Project B
    Project C
  Product Bar [trunk]       <- is a workspace
    Project A
    Project B
    Project C

• Refactor and streamline the workbench so that the barrier for entry for new contributors is reduced. -- Him Korne
• I think that macro recording and playback (bug 8519) should be part of the 4.0 plan. This is one of the most voted-for bugs, and one of the few features where Eclipse falls short of commercial closed-source solutions. The reason why this can not be addressed in Eclipse 3 is that in an open ecosystem of plugins contributed by multiple different sources, macro recording and playback can only be provided consistently when all plugins "play by the rules", i.e. adhere to a common API needed for scripting. In other words, they need to offer their functionality not only by menu actions, views and key commands but also by scriptable commands; and, when macro recording is turned on, they need to pass the actions they perform into the macro recorder. I'd think that for Eclipse 4, the Platform should come up with the APIs and Rules that plugins need to implement if they want to be part of macro recording and playback. Given that it would not be user friendly if a macro recorder would supporrt "most" but not all actions performed by the user, plugins should be strongly encouraged to follow those rules. --Martin Oberhuber
• Wizards are modal dialogs in Eclipse 3.x. This makes programming easier, since you can rely on resources not changing. (and it makes wizards harder to use). With the idea in e4 to separate client and server and make e4 a multiple user architecture, this assumption of non changing resources fails anyway. It doesn't make sense for me to use the dialog metaphor for wizards in e4. For me, wizards aree more an editor thing. See 147762 -- Gerd Castan
• On nested workspaces/projects:
  • IMO this would also mean to be able to structure the preferences hierarchically along the same lines. Years ago i had used the Together IDE and there it was possible to define settings on all 3 levels of the workspace tree (default/project/item) and every settings dialog would support it, that is view in side to side comparison the settings on each level. to give a use case: some settings rarely change between projects/workspaces they just evolve overtime, e.g. keyboard short cuts. when using multiple workspaces i have to keep them in sync manually - a real pain. see also Preferences -- thomas menzel
  • recursive sync with the repository in regard to adding/removing sub projects. currently this need to be done manually with import/delete project. -- thomas menzel