This page is under construction.
For now we'll use this to capture the list of work items that we intend to address during the 4.2 development cycle.
Productizing Eclipse 4
This section deals with the tasks necessary to bring Eclipse 4's functionality up to par with 3.x as regards using 4.x as the basis for enterprise applications.
Eclipse 4 RCP Improvements
This section contains tasks oriented towards the improving the Eclipse 4 RCP story.
Consuming new Eclipse 4 Features
These are the tasks needed to allow both existing and new Eclipse plug-ins to gain access to Eclipse 4's underlying API and use these to enhance their own component's User Interface.
- Working alongside other DI mechanisms
- DI and Events
- bug 351363 RCP Views: We have to refactor some of the more common views to be usable in 4.x RCP apps without dragging in the compatibility payer. This will mean changes in both the 3.x and 4.x streams since it will mean turning these views into 'real' 4.x parts and then hosting them in 3.x through the use of Tom's 'forward compatibility' layer.
- bug 280358 Intro: We have to provide a 4.2 specific implementation for the IntroManager. We should be able to do this in a more organized fashion than currently exists in 3.x
- bug 320021 Splash: We need to update the splash screen so that it is at least equivalent to the 3.x version. Note that this will depend on out getting the startup logic fixed at least to the point of not 'finishing' until the UI is actually displayed.
- bug 351366 Hosted Views / Editors: We have to allow views and editors to be hosted in Dialogs, Wizards etc. At the moment it appears that there are a number of places (i.e. selection) where a part that isn't the active part doesn't work (and you also can't make a part that isn't part of the presentation structure active).
- bug 349867 DnD Polish: We've got to be able to do something better than the feedback we currently have. Also need to implement DnD for trim elements...
- bug 351367 Investigate eliminating the use of 'deltas': We need to see if there's an alternative implementation in which the model is stored using the EMF mechanisms. By preference we'd prefer to include the Menu/TB info in the saved model and handle missing bundles etc during rendering / run time rather than trying to clear the elements out of the model before saving.