Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Eclipse4/KnownIssues/4.0"

(New page: The Eclipse SDK 4.0 Early Adopter release is not intended to replace the Eclipse 3.6 SDK. Its primary focus is to allow developers of other Eclipse projects and plug-ins to prepare for a ...)
 
(Plug-in developer features)
Line 3: Line 3:
 
This page summarizes the major features that we have intentionally deferred in order to ship the release, and some discussion about how these features could reappear in a future release.
 
This page summarizes the major features that we have intentionally deferred in order to ship the release, and some discussion about how these features could reappear in a future release.
  
= Plug-in developer features =
+
= Missing API/Developer functionality =
 
* NLS support for model files
 
* NLS support for model files
 
* Bidi support
 
* Bidi support
 
* Capabilities are not supported.  UI will appear whether the capability is enabled or not.
 
* Capabilities are not supported.  UI will appear whether the capability is enabled or not.
 +
* All API is provisional.  Since the purpose of the 4.0 release is to get a wider community adopting the technology, we are leaving ourselves an additional release to get the API right, based on developer feedback.
  
 
= End user features =
 
= End user features =
 
* Key bindings UI - in 4.0, the user must edit the workbench model description to add or change key bindings.  This proves the viability of adding key bindings to a modeled workbench, but of course we don't expect this to be the way that end-users would add bindings.
 
* Key bindings UI - in 4.0, the user must edit the workbench model description to add or change key bindings.  This proves the viability of adding key bindings to a modeled workbench, but of course we don't expect this to be the way that end-users would add bindings.
 
* Customize perspective - given the increased flexibility allowed by a modeled UI (for things like mixing views and editors, not sharing editor areas, ignoring perspectives completely), we have not put effort in the 4.0 release into modelling the same functionality as in Eclipse 3.6.  Future releases will bring perspectives up to par, and likely surpass the capabilities and increase the flexibility of the 3.x perspective model.
 
* Customize perspective - given the increased flexibility allowed by a modeled UI (for things like mixing views and editors, not sharing editor areas, ignoring perspectives completely), we have not put effort in the 4.0 release into modelling the same functionality as in Eclipse 3.6.  Future releases will bring perspectives up to par, and likely surpass the capabilities and increase the flexibility of the 3.x perspective model.

Revision as of 11:08, 15 July 2010

The Eclipse SDK 4.0 Early Adopter release is not intended to replace the Eclipse 3.6 SDK. Its primary focus is to allow developers of other Eclipse projects and plug-ins to prepare for a future Eclipse simultaneous release built upon it. In order to ship an SDK based on entirely new underlying architectures, we have had to defer some major features that would normally be expected to appear in an Eclipse SDK release. (See the Eclipse SDK 4.0 Early Adopter FAQ for more details about the release).

This page summarizes the major features that we have intentionally deferred in order to ship the release, and some discussion about how these features could reappear in a future release.

Missing API/Developer functionality

  • NLS support for model files
  • Bidi support
  • Capabilities are not supported. UI will appear whether the capability is enabled or not.
  • All API is provisional. Since the purpose of the 4.0 release is to get a wider community adopting the technology, we are leaving ourselves an additional release to get the API right, based on developer feedback.

End user features

  • Key bindings UI - in 4.0, the user must edit the workbench model description to add or change key bindings. This proves the viability of adding key bindings to a modeled workbench, but of course we don't expect this to be the way that end-users would add bindings.
  • Customize perspective - given the increased flexibility allowed by a modeled UI (for things like mixing views and editors, not sharing editor areas, ignoring perspectives completely), we have not put effort in the 4.0 release into modelling the same functionality as in Eclipse 3.6. Future releases will bring perspectives up to par, and likely surpass the capabilities and increase the flexibility of the 3.x perspective model.

Back to the top