RAP 1.1 New and Noteworthy

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

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.

  Button button = new ...
  button.setData( WidgetUtil.CUSTOM_WIDGET_ID,
                  "org.sample.LoginDialog#okButton" );
          

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 ...
      shell.layout();
      shell.open();
      while( !shell.isDisposed() ) {
        if( !display.readAndDispatch() ) {
          display.sleep();
        }
      }
      return 0;
    }
  }
          

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.

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

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

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

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

See API documentation for more information.

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

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.

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 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.
Example:

See API documentation for more information.

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 );
    }
  
  [...]
              

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 ) {
      e.printStackTrace();
    }
    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.