Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Platform UI/Plan/4.7

Planning page for Oxygen (4.7)

You find all bugs targeted for this release in our Eclipse 4.7 milestone wiki. The note and newsworthy of all Eclipse top-level projects can be found under Eclipse Oxygen Note and Newsworthy.

Performance and stability

The Eclipse Platform UI team need to continue to improve stability and performance of the user interface. This includes improving the initial startup time of the Eclipse IDE as well as improving the interactive performance. We will also evaluate performance issues reported by automatic error reporting tools like Sonar and Findbugs and try to solve as many as possible.


Simplify and improve the user experience

The Eclipse Platform UI team plans to continue to simplify the user workflow in the Eclipse IDE. This may include the retirement of existing import wizards, now that the smart import wizard has been integrated into 4.6 but also other items, like the simplification of the menu structure in the Eclipse IDE.


Code cleanup, Simplify platform API and simplification of the committer and contributor workflow

The Eclipse Platform UI team will continue to simplify the workflow of existing and new committers and contributors. This includes the activation of more test suites during the Gerrit build trigger, code cleanup, migration of the tests to modern constructs (JUnit4, modern Assert frameworks, etc). It also includes the update of the code to remove compiler warnings. To be more inviting to other Open Source contributors we also need to update our code with constructs of modern Java versions.

Also the Eclipse Platform UI team plans to clean-up the bug database. Currently the bug database is full of outdated an already solved bugs, which makes finding real problems in the bug database complex.

For the platform UI work see bug 468000 and for the general work together with the Eclipse foundation see bug 435599.

The Eclipse Platform UI team plans to simplify their API for platform clients. It also plans to evaluate and, if possible, implement generics and varargs in its API. This journey started in 4.4 but needs to continue.


Improvements in the Jobs API and usage

We will change the calling convention for methods which receive an IProgressMonitor. See bug 487372 for details. We will also provide error logging for jobs which do not check for cancellation. See See bug 470175. Also the Jobs internal will be reworked to be more responsive, for example if the job updates its message to frequently.


JFace Databinding enhancements

The Eclipse Platform UI team plans to continue to improve the JFace Databinding API. Examples are generics work but also several other updates.


Support a less disruptive work mode by moving popups and dialogs to inline editing and notifications

Eclipse popups and dialogs can distract the workflow of the user. The Platform UI team should evaluate if popups can be avoided and notifications or inline editing can be used. For example, renaming a resource should be possible without a dialog. Notifications about a finished job should not require a dialog, etc.

To archive this the Eclipse Platform UI team plans to migrate the Mylyn notification framework to platform UI. This change has been discussed with the Mylyn team and was well received.


Improvements in the default theme and the CSS styling for the dark theme

The Platform UI team will enhance the default styling on all platform to enhance the Eclipse IDE experience. This involves reducing the visual clutter and using consistent colors.

The Eclipse Platform UI team plans to work together with the SWT team to improve the styling possibilities of the Eclipse IDE and to improve the default dark theme of the Eclipse IDE.


Provide a default spelling engine in Platform Text instead in JDT UI

The spelling engine implementation should be moved from JDT UI to Platform Text, so that non JDT projects can leverage its implementation (bug 185695).


Reducing cost of basic support for new languages

The text editor framework could provide some basic features for most file types without the need to specialize it and to create a specific editor, but only relying on external services or an internal registry of grammars to add that behaviour. See bug 486961 for details


Providing a framework for asynchronous code completion

Currently code completion call are happening in the main thread. The text framework should provide a way to perform this asynchronously. See bug 251156 for details


Back to the top