Twitter Logo Follow us on Twitter
Project Information About this project

RAP 1.1 New and Noteworthy

Here are some of the more noteworthy things available in RAP 1.1 (June 25, 2008) which is now available for download.

This list shows all bugs that were fixed.



CVS Reorganization Since the number of RAP projects has increased in the past, we decided to reorganize the structure of our source code repository to make it more concise. Thus we started to introduce different subfolders.

Besides the sandbox there's now a new folder called runtime which contains the projects

  • org.eclipse.rap.jface,
  • org.eclipse.rap.jface.databinding,
  • org.eclipse.rap.ui,
  • org.eclipse.rap.ui.forms,
  • org.eclipse.rap.ui.views, and
  • org.eclipse.rap.ui.workbench
which have been adopted to the Eclipse 3.4 code base. If you work against CVS, you have to replace the old versions of these projects with those from the runtime folder.

The CVS reorganization is an ongoing effort and is scheduled to be finished shortly after the RAP 1.1 release. If you want to stay tuned, you can set yourself CC to bug #201257.

The team project sets provided here are in sync with the current CVS structure.


Support for Custom Widget Id's In RWT, each widget has an automatically generated, unique widget id that associates the server-side object with its client-side representation.
In order to use automated UI tests, now the generated id can be overridden programmatically. With code like this:
  Button button = new ...
  button.setData( WidgetUtil.CUSTOM_WIDGET_ID,
                  "org.sample.LoginDialog#okButton" );
and the system property org.eclipse.rwt.enableUITests turned on, the button can always be identified by its custom id. The test scenario can remain unchanged even if the UI changes.

See this bug and the JavaDoc for WidgetUtil#CUSTOM_WIDGET_ID and WidgetUtil#ENABLE_UI_TESTS for further information.
Browser#execute() The org.eclipse.swt.browser.Browser#execute(String) method was implemented. This method allows to execute a script containing JavaScript commands.

Please read the JavaDoc for further details.
Display#readAndDispatch() To more closely align with SWT and solve the problems with the existing mechanism for blocking UI operations, RWT new provides Display#readAndDispatch() and Display#sleep().

The new implementation now strictly follows the apartment threading model. This means that the life cycle is handled by a single thread, spanning the lifetime of a session. As a result, all phase listeners and application code are executed on this thread. Note, that the readAndDispatch() loop runs in the process action phase, however this is generally transparent to the application developer.

Please be aware that this comes at the cost of a small API break. The IEntryPoint#createUI method changed its signature from Display create() to int createUI. A typical entry point that creates a workbench would now look like this:

  public class MyApplication implements IEntryPoint {
    public int createUI() {
      Display display = PlatformUI.createDisplay();
      WorkbenchAdvisor advisor = new MyWorkbenchAdvisor();
      return PlatformUI.createAndRunWorkbench( display, advisor )

If you are using RWT directly, you also need to code the typical event loop in your entry point:

  public class MyEntryPoint implements IEntryPoint {
    public int createUI() {
      Display display = new Display();
      Shell shell = new Shell( display );
      shell.setSize( 560, 420 );
      // ... populate shell here ...
      while( !shell.isDisposed() ) {
        if( !display.readAndDispatch() ) {
      return 0;

Table keyboard navigation The table widget now supports keyboard navigation. Using the Up, Down, Home, End, PageUp and PageDown keys works as expected.
UI Styling API Support for background images
The methods Control#get/setBackgroundImage() allow to set background images on almost all controls.

Support for transparency
The methods Composite#get/setBackgroundMode() are now available. Setting the background mode of a control to SWT.INHERIT_DEFAULT lets all labels, links, checkboxes etc. on this composite inherit its background color and image.

Semi-transparent Shells
Thanks to the SWT 3.4 method get/setAlpha(), Shells can now be semi-transparent. This feature is also useful to place a shading layer below a modal dialog window as seen on some Web 2.0 sites.

Theming Variants It is now possible to define variants of widget types that can be styled separately. As an example, an application that uses PUSH buttons in a special side bar can define a variant "side-button" and apply a different styling to these buttons. This styling only applies to the buttons belonging to the variant and does not affect any other PUSH buttons in the application.

The variant is set using the widget user data (Widget#setData()), so the code remains 100% SWT compatible.

ISettingStore There is a new subsystem in RWT that allows to persist user-specific settings:

RWT.getSettingStore().setAttribute( "myAttribute", "myValue" );.

The setting store allows to restore settings made in a previous session:

RWT.getSettingStore().getAttribute( "myAttribute" );.

The setting store uses browser cookies to identify the settings of previous sessions.
It is also possible to load specific settings independently from cookies:

RWT.getSettingStore().loadById( "myId" ).

This is for example useful in case that certain settings should only be available after the user has gone through an authentication process.
Note that the setting store subsystem is used by the new ScopedPreferenceStore implementation of the workbench.

See API documentation for more information.

Mouse Events RWT now has support for MouseEvents. Calling addMouseListener on a Control will notify you about mouseUp, mouseDown and mouseDoubleClick events.

Please be aware that, despite the complete API, there are still some limitations that will be addressed in the future.

RWT Split-up RWT has been split into a host bundle and qooxdoo 0.7 fragment. This was done to enable us to start working on the upcoming qooxdoo 0.8 version. This split-up will also allow interested parties to develop other client-side implementations for RAP in the future.

Developers who work against CVS have to check out the fragment org.eclipse.rap.rwt.q07 and include it in their launch configurations.

Note: Customize your build process so that the org.eclipse.rap.rwt.q07 fragment is included. Ensure also that it's listed under the osgi.bundles property in your config.ini but doesn't get started.

Theming Support for theme files in CSS format
RAP supports theme files in CSS syntax now. CSS theme files for RAP must be valid CSS 2.1 files, except for a couple of RAP specific properties and pseudo classes.

The following is an example for a simple CSS theme file:

  * {
    backgound-color: white;
  Button[PUSH], Button[TOGGLE] {
    border: 2px solid blue;
    color: rgb( 17, 23, 103 );
    background-color: #f9f9f9;
  Button[PUSH]:hover, Button[TOGGLE]:hover {
    background-color: white;

The support for the new syntax is just the first step towards a more flexible theming. Internally, the theming engine is still based on the old properties. As an effect, only a subset of the flexibility provided by CSS is already supported. For more information on the topic, have a look at the RAP Help.

Developers are encouraged to write CSS theme files now. The old property-based theme files are still supported but considered deprecated.

JFace and Workbench

Image Decorator Support

JFace now contains class org.eclipse.jface.viewers.DecorationOverlayIcon that supports the creation of image overlays for decoration (org.eclipse.jface.resource.CompositeImageDescriptor is now fully functional).

The workbench now provides the extension point org.eclipse.ui.decorators which allows to add decorations declaratively based on enablements.

Support for activities The RAP Workbench now supports the org.eclipse.ui.activities and org.eclipse.ui.activitySupport extension points. You can control the visibility of views, editors, perspectives, menu and toolbar items using activities and trigger points. See the extension point documentation for details.

RAP HttpContext The RAP servlet now uses its own HttpContext implementation. This allows other servlets to map to that context too. This enables the possibility to share the same session instances between those servlets and the RAP servlet for data exchange.

ScopedPreferenceStore The RAP workbench provides now org.eclipse.ui.preferences.ScopedPreferenceStore that allows to read and set user-specific preferences using the preference mechanism provided by org.eclipse.core.runtime. The base of the storage mechanism is a subsystem of RWT represented by org.eclipse.rwt.service.ISettingStore. The session aware org.eclipse.jface.preference.IPreferenceStore can be retrieved using the method org.eclipse.ui.plugin.AbstractUIPlugin.getPreferenceStore.

See API documentation for more information.

Import-/Export Wizards RAP supports now Import- and Exportwizards by providing the extension points importWizards and exportWizards. See also ActionFactory.IMPORT and ActionFactory.EXPORT for opening the import-/export wizard.

Eclipse 3.4 Adoption The RAP counterparts of JFace, Workbench, Forms and Databinding have been migrated to the 3.4 code base.

During this effort, we tried to achieve feature completeness as far as possible to get a clear picture of what is needed to enable single sourcing of the RAP and RCP Workbench in the future.

Here are some of the more noteworthy things that are now available:

  • Presentation

    The workbench demo comes with a presentation sketch that makes use of the newly adopted presentation support. Launch the demo and use Window > Preferences > Demo Prefernce Page to switch between the available presentations. After that, you need to reload the browser page in order to see the changes.

  • Preference Pages

    Support for preference pages is now available. Note that in order to keep preference settings session scoped, you need to initialize the PreferenceStore of the page with a suitable PreferenceStore. AbstractUIPlugin#getPreferenceStore() returns such an implementation.

  • IMemento for workbench state persistence

    The save and restore mechanism must be activated like shown in the snippet below.

    public class DemoWorkbenchAdvisor extends WorkbenchAdvisor {
      public void initialize( IWorkbenchConfigurer configurer ) {
        getWorkbenchConfigurer().setSaveAndRestore( true );
        super.initialize( configurer );


RAP JUnit RAP provides an equivalent to the "PDE JUnit Tests" to allow to run tests that require an OSGi environment up and running.

The snippet below shows how a RAP JUnit test case looks like. To compile such a test, the containing plug-in needs a dependency on org.eclipse.rap.junit. This allows to use the RAPTestCase that provides UI-Updates during the tests. If you don't want to see UI-updates during the test runs, you can directly use org.junit.TestCase instead.

In order to run a test, choose Run As > RAP JUnit Test from the editors' context menu.

public class RapJUnitTest extends RAPTestCase {
  public void testOpenView() {
    try {
      IWorkbenchPage page = getPage();
      page.showView( "org.eclipse.rap.demo.DemoTreeViewPartI" );
    } catch( PartInitException e ) {
    assertEquals( 1, getPage().getViewReferences().length );

    getPage().hideView( getPage().getViewReferences()[ 0 ] );
    assertEquals( 0, getPage().getViewReferences().length );

  private IWorkbenchPage getPage() {
    IWorkbench workbench = PlatformUI.getWorkbench();
    IWorkbenchWindow window = workbench.getActiveWorkbenchWindow();
    return window.getActivePage();

RAP JUnit supports only the 3.x Test Runner at the moment.