Skip to main content
Jump to: navigation, search

Platform UI/Plan/4.5

Planning page for Mars

Our planning list and assumptions are Platform UI/Plan/4.5/Planning Bugs.


Performance and stability of Platform user interface

Version 4.4 of the Eclipse Platform still has some performance and functional shortcomings compared to the old 3.x generation of the platform. We will work to root out and eliminate most of these remaining bugs to increase the overall quality and performance of the 4.x generation platform. We are also planning to address memory leak issues that have been found in the 4.x version.

We will continue to focus on regressions, and improvements in the UX workflows.

Ease and help with the transition of 3.x RCP applications to 4.x

Support the community in their transition to 4.5 and add APIs where necessary to get wider adoption. We will focus on the issues that are blockers for migration, providing proper patches and advising some workarounds for lacking functionality.

Recruit and train new contributors

While adoption and use of the Eclipse Platform increases every year, there has been a steadily declining rate of contribution back to the platform's development. We will work to reduce any real or perceived barriers to contribution, and increase efforts on reviewing patches and mentoring new contributors, with the goal that they become active committers.

Other items that we would like to consider in Mars

Exposing Eclipse4 in the Workbench

Migration path for 3.x plugins

  • Figure out how a 3.x extension point can take advantage of contexts and DI

Hosting Eclipse4 Models

The Workbench (a.k.a compatibility layer) manipulates the model to host 3.x views and editors on it. In Mars we'd like to see Eclipse4 parts and other contributions contributed to the Workbench and provide 3.x wrappers to correctly interact with them in the Workbench.

Menus, Commands, and Handlers

Handlers in the Workbench are currently clustered on their own IEclipseContext just off of the application context. The handlers in Eclipse4 can be instantiated at any MContext level, and that controls their activation and enablement much finer grained. The goal is to expose this distribution on handlers contributed through the Workbench.

IEclipseContext and DI Use

The IEclipseContext represent a runtime hierarchy of information. The goal is to have a regular pattern and predictable use, so that looking up information at any point in the hierarchy will return the appropriate answer.

Some mechanisms it supports we need to rationalize:

  1. setting the value for a variable, and then use context.getActiveLeaf().get(variable)
  2. using context.modify(variable, value) and then using context.get(variable)
  3. setting a variable in the application context that points to a ContextFunction. context.get(variable) will apply the ContextFunction to the current hierarchy.
  4. Review what data is in the context and whether it belongs elsewhere such as transient data.
  5. Investigate how to provide bulk updates to contexts efficiently
  6. Investigate threading problems

Fragments and Extension Points

The fragment processing needs some more design work. The goal is to simplify the creation of fragments and to apply them in a standard way that is predictable.

It would be nice if there was a tool where you could create your structure, select elements, and generate a fragment.

Graduate Relevant Eclipse4 tools

There are tools still in the E4 incubator that we should look at graduating or moth balling in Mars. Some currently under consideration:

The Lightweight CSS editor will probably need some work before it can graduate, as it would bring in the XText runtime. See bug 426397 - Provide an eclipse editor based on OrionEditorControl

Eclipse Application Services

See E4/Eclipse Application Services as a starting point, although our understanding has changed some of the categories.

Logging and Tracing

We need to decide on our logging and tracing strategies, and which APIs to use (ex, just use Equinox Logging and DebugTrace or SLF4J?). Then we need to apply that strategy to many of our new Eclipse4 plugins.

Save Lifecycle

We need to provide the fully functioning Eclipse4 save lifecycle, that the Workbench save lifecycle can be implemented on top of.

Workbench Services Decoupling

It's always been our goal to break up many of the Workbench services so they can be consumed by Eclipse4 applications without consuming the entire Workbench. Some examples:

  • ISharedImages service
  • Progress view service - Some work done on this in Luna, see bug 429505 - [Progress] Refine Eclipse4 based progress view
  • Error log service
  • Preference management
  • Properties management
  • New wizards

Our starting priority here was the Error log and Progress view.

Application Startup and Lifecycle

The goal is that the Eclipse4 application startup and lifecycle make sense, and the Workbench startup fits in the appropriate place.

For example, it's reasonable that the Workbench startup should create a useful model that can then be passed to the Eclipse4 application startup. There are a number of lifecycle hooks that should probably be made available in the Eclipse4 startup.

There are also more general discussions about lifecycle:

CSS Enhancements

The goal here is to improve our CSS story.

  • The workflow of how we load and use CSS within eclipse
  • Enhancements to use it more throughout SWT.
  • How the CSS interacts with the Model

Back to the top