Skip to main content
Jump to: navigation, search

Difference between revisions of "Platform UI/Plan/4.6"

(Created page with "= Planning page for Mars = Our planning list and assumptions are Platform UI/Plan/4.5/Planning Bugs. = Themes = == Performance and stability of Platform user interface =...")
 
m
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Planning page for Mars =
+
= Planning page for Neon =
  
Our planning list and assumptions are [[Platform UI/Plan/4.5/Planning Bugs]].
+
You find all bugs targeted for this release in our [http://wiki.eclipse.org/Platform_UI/Plan/4.6/Milestones Eclipse Neon milestone wiki]. The note and newsworthy of all Eclipse top-level projects can be found under [https://www.eclipse.org/eclipse/news/4.6/ Eclipse Neon Note and Newsworthy].
  
 
= Themes =
 
= Themes =
== Performance and stability of Platform user interface ==
+
== Performance and stability ==
  
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.
+
The Eclipse Platform UI team need to continue to improve stability and performance of the user interface. This includes regressions but also improvements compared to 3.x. The UI freeze monitoring and the reports created by the automatic error reporting tooling will also be used for this activity.
  
We will continue to focus on regressions, and improvements in the UX workflows.
+
Items for improvements are improved performance in the the rendering of the  SWT based components, the option to disable CSS styling via preferences and improve handling of background jobs.
  
== Ease and help with the transition of 3.x RCP applications to 4.x ==
+
== Simplify and improve the user experience ==
  
Support the community in their transition to 4.5 and add APIs where necessary to get wider adoption.  
+
The Eclipse Platform UI team plans to simplify the user workflow. For example, by adding the smart import wizard to platform, the user experience for importing project should be improved. We also plan to provide user enhancements like shortcuts for increasing the font size in an editor.
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 ==
+
It is also planned to finish the support of HDPI screens ({{bug|382972}}) which was started in Eclipse 4.4. but unfortunately not finished due to some late discovered issues.
  
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 also provide a full screen mode in which the user can hide the currently displayed trimbars and toolbars to maximize his work area.
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.
+
  
 +
== Code cleanup==
  
= Other items that we would like to consider in Mars =
+
The Eclipse Platform UI team plans to reduce references to internal API from the code. We also work on removing dead internal code and to remove references to deprecated API. We will also investigate if we can use @Nullable and @NotNullable annotations. We will also retire outdated examples and put them on Github.
  
== Exposing Eclipse4 in the Workbench ==
+
In case several options exists in our API and one option should be preferred, we will provide clearer guidanceto the platform API adapters which API should be used by using the @Deprecated annotation.
  
=== Migration path for 3.x plugins ===
+
== Improvements in the Jobs API and usage==
  
* Figure out how a 3.x extension point can take advantage of contexts and DI
+
The Eclipse Platform UI team plans to improve the performance of the Jobs framework, focusing on the usage of SubMonitor and its performance. For this we will cooperate with Equinox and other project to replace the usage of SubProgressMonitor.
  
=== Hosting Eclipse4 Models ===
+
== Consistent usage of adapters==
  
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.
+
The Eclipse Platform UI team plans to work with Equinox to improve the handling of adapters in platform.ui. The target is to replace isolated adapter solutions in the platform.ui code, simplify the usage of the adapter pattern and provide a consistent API.
  
=== Menus, Commands, and Handlers ===
+
== Simplify platform API==
  
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.
+
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. Generics are planned to be evaluated at for JFace Dialogs, the JFace Viewers and JFace Databinding.
  
== IEclipseContext and DI Use ==
+
== Simplify committer and contributor workflow==
  
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.
+
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.  
  
Some mechanisms it supports we need to rationalize:
+
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.
  
# setting the value for a variable, and then use context.getActiveLeaf().get(variable)
+
For the platform UI work see {{bug|468000}} and for the general work together with the Eclipse foundation see {{bug|435599}}.
# using context.modify(variable, value) and then using context.get(variable)
+
# setting a variable in the application context that points to a ContextFunction.  context.get(variable) will apply the ContextFunction to the current hierarchy.
+
# Review what data is in the context and whether it belongs elsewhere such as transient data.
+
# Investigate how to provide bulk updates to contexts efficiently
+
# Investigate threading problems
+
  
== Fragments and Extension Points ==
+
== Rework platform ui tests ==
  
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.
+
The team plans to migrate all existing tests to JUnit 4 and evaluate the usage of better matching frameworks to simplify the tests. As far as possible, all tests should be configured to run via the Gerrit build trigger to ensure stability of the code contributions.
  
It would be nice if there was a tool where you could create your structure, select elements, and generate a fragment.
+
== Enhance Eclipse RCP programming model ==
  
== Graduate Relevant Eclipse4 tools ==
+
The Eclipse model should be improved. For example, enhancements are planned for modeling wizards and dialogs as well as handling of core expressions. Core expressions are currently only evaluated for tool and menu items but should also be evaluated for toolbars. It is planned to evaluate if the additional dependency to javax.annotation can be removed in platform without breaking existing clients.
  
There are tools still in the E4 incubator that we should look at graduating or moth balling in Mars.  Some currently under consideration:
+
== Java 8 support in JFace Databinding ==
  
* http://marketplace.eclipse.org/content/eclipse-4-tools-lightweight-css-editor
+
The Eclipse Platform UI team plans to support the new Date and Time API from Java 8 in JFace Databinding.
* http://marketplace.eclipse.org/content/eclipse-4-tools-css-spy
+
* http://marketplace.eclipse.org/content/eclipse-4-tools-application-model-editor
+
* Context debug view
+
  
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
+
== Migrate Mylyn notifications framework to platform UI ==
  
== Eclipse Application Services ==
+
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.
  
See [[E4/Eclipse Application Services]] as a starting point, although our understanding has changed some of the categories.
+
== CSS Enhancements and better support for the dark theme ==
  
=== Logging and Tracing ===
+
The Eclipse Platform UI team plans to enhance CSS support. A new CSS parser will be evaluated to support CSS 3.0 and to improve performance. The Eclipse Platform UI team will continue to cooperate with other teams like JDT and SWT to improve the styling capabilities in general and the dark theme as a special use case of the CSS styling.
 
+
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
+

Latest revision as of 06:16, 22 January 2016

Planning page for Neon

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

Themes

Performance and stability

The Eclipse Platform UI team need to continue to improve stability and performance of the user interface. This includes regressions but also improvements compared to 3.x. The UI freeze monitoring and the reports created by the automatic error reporting tooling will also be used for this activity.

Items for improvements are improved performance in the the rendering of the SWT based components, the option to disable CSS styling via preferences and improve handling of background jobs.

Simplify and improve the user experience

The Eclipse Platform UI team plans to simplify the user workflow. For example, by adding the smart import wizard to platform, the user experience for importing project should be improved. We also plan to provide user enhancements like shortcuts for increasing the font size in an editor.

It is also planned to finish the support of HDPI screens (bug 382972) which was started in Eclipse 4.4. but unfortunately not finished due to some late discovered issues.

We will also provide a full screen mode in which the user can hide the currently displayed trimbars and toolbars to maximize his work area.

Code cleanup

The Eclipse Platform UI team plans to reduce references to internal API from the code. We also work on removing dead internal code and to remove references to deprecated API. We will also investigate if we can use @Nullable and @NotNullable annotations. We will also retire outdated examples and put them on Github.

In case several options exists in our API and one option should be preferred, we will provide clearer guidanceto the platform API adapters which API should be used by using the @Deprecated annotation.

Improvements in the Jobs API and usage

The Eclipse Platform UI team plans to improve the performance of the Jobs framework, focusing on the usage of SubMonitor and its performance. For this we will cooperate with Equinox and other project to replace the usage of SubProgressMonitor.

Consistent usage of adapters

The Eclipse Platform UI team plans to work with Equinox to improve the handling of adapters in platform.ui. The target is to replace isolated adapter solutions in the platform.ui code, simplify the usage of the adapter pattern and provide a consistent API.

Simplify platform API

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. Generics are planned to be evaluated at for JFace Dialogs, the JFace Viewers and JFace Databinding.

Simplify 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.

Rework platform ui tests

The team plans to migrate all existing tests to JUnit 4 and evaluate the usage of better matching frameworks to simplify the tests. As far as possible, all tests should be configured to run via the Gerrit build trigger to ensure stability of the code contributions.

Enhance Eclipse RCP programming model

The Eclipse model should be improved. For example, enhancements are planned for modeling wizards and dialogs as well as handling of core expressions. Core expressions are currently only evaluated for tool and menu items but should also be evaluated for toolbars. It is planned to evaluate if the additional dependency to javax.annotation can be removed in platform without breaking existing clients.

Java 8 support in JFace Databinding

The Eclipse Platform UI team plans to support the new Date and Time API from Java 8 in JFace Databinding.

Migrate Mylyn notifications framework to platform UI

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.

CSS Enhancements and better support for the dark theme

The Eclipse Platform UI team plans to enhance CSS support. A new CSS parser will be evaluated to support CSS 3.0 and to improve performance. The Eclipse Platform UI team will continue to cooperate with other teams like JDT and SWT to improve the styling capabilities in general and the dark theme as a special use case of the CSS styling.

Back to the top