Twitter Logo Follow us on Twitter
Project Information About this project

RAP 1.0 - New and Noteworthy

Here are some of the more noteworthy things available in the first release build (October 10, 2007) which is now available for download.

RAP Common

RCP Namespaces After many RAP users have requested it and after discussing this topic with the SWT and Platform team we have moved org.eclipse.rwt.rap to org.eclipse.swt, org.eclipse.rap.jface to org.eclipse.jface and org.eclipse.rap.ui to org.eclipse.ui package names. This should ease the task of adopting RCP code to RAP. To adjust your existing projects to the new packages you may use the organize imports functionality of eclipse.

Note: RAP will provide a strict subset of the established API in those namespaces.


RWT

Robustness Several enhancements were made to react on unexpected situations more smoothly.

When a request is sent to an expired or otherwise invalidated session, now a (yet very basic) HTML page informs the user what happened and provides a link to restart the session.

To deal with bad connections or temporarily unavailable servers, now a message box appears, that gives the user a chance to retry sending the request.

Error Handling In the case of a server-side programming error that leads to an exception which is not handled by the Workbench or other error handling facilities, it is now passed to the servlet engine. The client-side reacts accordingly and displays the error page as it was sent by the servlet engine.

In case of a JavaScript error, that occurs while the server response is being processed, an error page displays the error message along with the code that caused it.

Text Size Determination API The API that serves as replacement for the SWT-GC functionalities for text size determination has been created. The methods textExtent(Font,String,int), stringExtent(Font,String), getCharHeight(Font) and getAvgCharWidth(Font) are available at the class org.eclipse.rwt.graphics.Graphics.

Table appearance The TableItem now supports all appearance settings known from SWT. For each cell the background color, foreground color, font and image can now be defined separately.

RAPTableAppearance.png

Tree with columns The Tree widget is now able to manage and display several columns per TreeItem. Also setting images for different cells and having nice headers are new features of the tree. As you can see on the screenshot, the default images are not needed anymore. Columns can be resized or packed to have an optimal user expierence.

RAPTreeColumns.png

New Table features The Table widget now notifies about double-click events by sending a SelectionListener#widgetDefaultSelected.

The column order can be queried and changed programmatically using getColumnOrder() and setColumnOrder(). Marking a column with setMoveable permits the user to change its order by drag and drop.

If a table is created with the SWT.VIRTUAL flag, TableItems are only realized client-side when they become visible. Even though, in most situations, using the TableViewer will be more convenient, the code below shows how the SetData event can be used to "manually" populate a VIRTUAL table.


Table table = new Table( shell, SWT.VIRTUAL );
table.addListener( SWT.SetData, new Listener() {
  public void handleEvent( final Event event ) {
    TableItem item = ( TableItem )event.item;
    int index = table.indexOf( item );
    item.setText( "Item " + index  );
  }
} );
table.setItemCount( 300 );
New widget: CLabel With the new CLabel widget you can now have images and text on your label without any workaround. Additionally you can set different border styles like SWT.SHADOW_IN or SWT.SHADOW_OUT. Here is an example how it could look like:

RAPCLabel.png

Cool stuff By reimplementing the CoolItem and CoolBar widget we got many improvements in this area. First is that support of multiple rows in the CoolBar which is used if there is not enough space to show all the items in one row.

RAPCoolBarRows.png

Additionally if there is not enough space to wrap the CoolItems a chevron will be visible to have access to the invisible items.

RAPCoolBarChevron.png


Theming enhancements The RAP theming infrastructure allows for further customizations of the UI. It is now possible to specify borders, paddings, fonts, and images in a custom theme file. Even custom widgets can now hook their theming into RAP using the extension point mechanism.

Some examples:

RAPTheming_Group.png

group.frame.border: 3 double #56a0ea
group.label.font: 12 bold Arial, Helvetica, sans-serif
...
button.background: #9dd0ea
button.border: 2 #1695d4
...

RAPTheming_LoginDialog.png


shell.BORDER.border: 3 #1695d4
shell.title.background: #9dd0ea
shell.title.padding: 2 5 2 2
shell.padding: 5
shell.button.margin: 0 2 8 0
...
text.BORDER.border: 1 solid #1695d4
...

For more information, see RAP Theming.

Client-side widget pooling RWT introduces a mechanism that helps to soften the massive memory consumption on the client. Many of the client-side widget are not thrown away anymore, but kept in an object pool for later reuse. Especially with long-running applications in the Internet Explorer browser, this can make a huge difference. The pooling does not include all RWT widgets now, so there is still potential for further optimization.

Please note that this topic is work in progress and, despite extensive testing, might lead to errors under rare circumstances. If you experience any inexplicable behavior, please let us know.

Text Size Determination With M5 a new text size determination has been developed. For more information of the technichal background you may look at http://wiki.eclipse.org/WidgetToolkit - Challenges/Text Size Calculation. Note that there are still some work items left to do.

With FireFox you can see the mechanism in action: Use Ctrl +/- to change font sizes. After refreshing the session (F5) RWT adapts to the new sizes.

Textsizedetermination.png

API Documentation The RWT-API classes now provide Java-Doc comments. These comments are adapted from the SWT library since RWT implements a subset of SWT. The revision of the comments is not completed yet and there may be also some anticipations of implementation details that ment to be available in the 1.0 release. If you find inconsistencies in the docs, please report them to us so that we can resolve them.

Untyped Events RWT now supports untyped events. Note that this implementation exists for reuse of JFace and Workbench code only. If you write application code we recommend to use the typed events furthermore. Note also that there is still some work to do and that not all of the untyped event fields already provide meaningful values. In particular the doit flag does not work.

FontData, Resource, Device There are new API-classes in RWT available. Those where needed to ease the takeover of the JFace resource package. The classes are org.eclipse.swt.graphics.FontData, org.eclipse.swt.graphics.Resource and org.eclipse.swt.graphics.Device. Note that the API of org.eclipse.swt.graphics.Font has changed, the field accessors have moved to FontData:

  ...
  FontData data = font.getFontData()[ 0 ];
  item.setFont( Font.getFont( data.getName(),
                              data.getHeight(),
                              SWT.BOLD ) );
Apartment Threading RWT simulates the Apartment Threading model of SWT. Because of this Display now provides the methods getThread, syncExcec, asyncExcec and wake. To enable UI-updates that are triggered from asynchronous server threads call org.eclipse.swt.lifecycle.UICallBackUtil.activateUICallBack. Accessing widget methods from non UI-Threads throws a SWTException. If you want to enable UI-updates all the time you may implement the createUI method of IEntryPoint like this:

  public Display createUI() {
    UICallBackUtil.activateUICallBack( getClass().getName() );
    final Display result = PlatformUI.createDisplay();
    PlatformUI.createAndRunWorkbench( result, new DemoWorbenchAdvisor() );
    return result;
  }
ProgressBar RWT provides a ProgressBar control. It can be used to show the progress of background tasks. You may have a look at the org.eclipse.rap.demo.controls.ProgressBarTab class in the demo plug-in to see how to use it.

ProgressBar.png

Table enhancements The SWT.CHECK style flag is now understood by the Table widget, along with the necessary methods and events to control and get notified about the checked and grayed state of TableItems.

Multi-selection can now be enabled by passing the SWT.MULTI style flag to the constructor. setSelection(*), getSelection(*), select(*) and deselect(*) will respect this flag and allow you to query and manipulate the current selection.

Except for setMovable() (controls whether columns can be reordered) the TableColumn API is now complete.

RapTableEnhancements.jpeg

Themeing An infrastructure for the themeing of RWT widgets has been implemented. This allows for customizing the look of RAP applications by applying a user defined theme. Currently, only colors and icons can be customized, but themeable fonts and borders will follow. For further information, have a look at RAP Themeing. The work on themeing is still in progress, comments and suggestions are welcome.

RAPThemeing.png

New Table features The Table widget now notifies about double-click events by sending a SelectionListener#widgetDefaultSelected.

The column order can be queried and changed programmatically using getColumnOrder() and setColumnOrder(). Marking a column with setMoveable permits the user to change its order by drag and drop.

If a table is created with the SWT.VIRTUAL flag, TableItems are only realized client-side when they become visible. Even though, in most situations, using the TableViewer will be more convenient, the code below shows how the SetData event can be used to "manually" populate a VIRTUAL table.


Table table = new Table( shell, SWT.VIRTUAL );
table.addListener( SWT.SetData, new Listener() {
  public void handleEvent( final Event event ) {
    TableItem item = ( TableItem )event.item;
    int index = table.indexOf( item );
    item.setText( "Item " + index  );
  }
} );
table.setItemCount( 300 );
ModifyEvent RWT now supports the ModifyEvent. The two widgets that benefit from this are Text and Spinner.

Though implementing a ModifyListener does not differ from SWT as You can see below, the inner workings do differ. In contrary to SWT that sends a ModifyEvent immediately, RWT uses a delay of currently 500 ms after which the server is notified about changes.

  Text text = new Text( parent, RWT.SINGLE );
  text.addModifyListener( new ModifyListener() {
    public void modifyText( ModifyEvent event ) {
      // update model with changed text
    }
  } );

Spinner Now there exists a Spinner widget that works much the same as in SWT.

RapSpinner.png

Default Button The default button was implemented, that You can now tell the Shell which of its buttons should behave as the default button. Just to have something to write for the next milestone news, the default button is not yet highlighted;)
Shell enhancements For dependent shells (aka dialog shells, those created with the Shell( Shell ) or Shell( Shell, int ) constructor), the escape key closes the shell.
Double click For List, Tree, and CTabFolder RWT now recognizes a double-click that is reported via the widgetDefaultSelected method of the SelectionEvent.

The screenshot below is taken from the RWT online demo, feel free to try it out yourself. RapDoubleClick.png

Focus control and FocusEvent In this development cycle we also put our focus on the focus. The methods setFocus, forceFocus, and isFocusControl of the Control class allow You to focus a control and query whether the control has the input focus. The getFocusControl on class Display tells You which control currently has the input focus.

When adding a FocusListener to a control, it will be notified about focusLost and focusGained events.

As of now, not all controls do visually indicate that they currently are focused.

Text enhancements The text widget has two new mini-features:
  • The setTextLimit and getTextLimit methods can be use to control and query the number of characters that may be entered.
  • All methods to control the text selection like setSelection and getSelection are implemented.

The following snippet, taken from the SelectionListener of the Show Selection button,

  Point sel= result.getSelection();
  String selText = text.getSelectionText();
  String msg = "Selection from " + sel.x + " to " + sel.y + " is " + selText;
  label.setText( msg );

leads to what is shown below

RapTextSelection.png


RAP JFace

Blocking Window Due to API compatibility to RCP we implemented a solution for blocking windows and removed the IWindowCallBack mechanism. Note that there is still some work behind the scence to do, since the current implementation may be a little heavy weighted. See the example snippet that shows how to use the blocking mechanism with the InputDialog.
    String title = "Input Dialog";
    String mesg = "Enter at least five characters";
    String def = "default text";
    final InputDialog dlg;
    dlg = new InputDialog( getShell(), title, mesg, def, val );
    int returnCode = dlg.open();
    if( returnCode == InputDialog.OK ) {
      inputDlgResLabel.setText( "Input Result: " + dlg.getValue() );
    } else {
      inputDlgResLabel.setText( "No Result" );
    }

TableViewer As the underlying RWT Table now understands the VIRTUAL flag, the relevant TableViewer code was activated as well. Below you can see how it looks in action.

Rap_VirtualTable_Loading.jpeg >>> Rap_VirtualTable_Done.jpeg

Move to JFace 3.3 You're reading it right - JFace 3.3 is here! This time, we used the complete JFace 3.3 codebase and stripped down the things not working (at the moment). As we can't support everything out of the box, here is a short list of things you can now use in your RAP application besides the already known stuff.
  • Action and Contribution infrastructure
  • Dialogs
    • IconAndMessageDialog
    • TrayDialog
    • TitleAreaDialog
    • PopupDialog
    • ErrorDialog
    • MessageDialogWithToggle
    • StatusDialog
    • ProgressIndicator
    • ProgressMonitorDialog
  • Layouts
    • GridDataFactory
  • Resources
    • Color-, Font- and ImageRegistry
  • Viewers
    • ArrayContentProvider
    • DecoratingLabelProvider, ILabelDecorator, LabelDecorator (only text yet)
    • DoubleClickEvent (for Treeviewer)
    • ViewerFilter
  • Wizard framework

There are many more things in the JFace 3.3 codebase - just get it and play around with it. We're open for all bug reports regarding the (new) components.

Note that some of the components (like DoubleClickEvent, ViewerFilter or the Wizard framework) are now part of the demo application.

RAP JFace implementation related to the following packages is excluded:

  • Keys & Bindings
  • Celleditors,
  • Owner Drawing
  • Field Assists

Most of them will follow but there is a need for some new infrastructure first. At the moment, you'll find the Java files of the excluded components but they are commented out to avoid confusion using "Organize Imports" or "Open Type".

RAPJFaceWizard.png

TableViewer As the underlying RWT Table now understands the VIRTUAL flag, the relevant TableViewer code was activated as well. Below you can see how it looks in action.

Rap_VirtualTable_Loading.jpeg >>> Rap_VirtualTable_Done.jpeg

Databinding Main functionalty of org.eclipse.jface.databinding has been ported to RAP. You can see databinding in action in the newly added perspective 'Databinding' in the RAP Demo application. Note that the databinding demo comes as a seperate plugin called org.eclipse.rap.demo.databinding which has to be started together with the regular workbench demo application. We would like to thank Samy Abou-Shama for his support in porting the databinding to RAP.

Here is a screenshot:

databinding_snippet_view.jpg

Dialogs RAP JFace now includes the base classes to implement dialogs like Window, WindowManager, Dialog, and IconAndMessageDialog and provides the most often used dialogs.
  • InputDialog

RapInputDialog.png

  • MessageDialog

RapQuestionDialog.png

  • ErrorDialog

RapErrorDialog.png

Due to the distributed nature of RAP, the way how the result is passed back to the caller differs from JFace. RAP JFace provides an IWindowCallback interface whose windowClosed method is called with the returnCode as a parameter when a dialog was closed.


Workbench

New extension points Commands can be implemented using org.eclipse.ui.handlers. With the org.eclipse.ui.menus extension point they can be placed in the main menu, view dropdown menus, context menus. They can also be added to the main toolbar, view toolbars, and various trim locations. The org.eclipse.ui.popupMenus extension point allows a plug-in to contribute to the popup menus of other views and editors. See org.eclipse.ui.popupMenus and org.eclipse.ui.menus documentation

Branding If you ever wanted to customize the startup page, the page title or even the servlet name you can now use the org.eclipse.rap.ui.branding extension point. You can specify your own branding, specify settings like page title, favicon, servletname, etc. There is also an additionalHeaders element available to define own tags for the head of your page like meta informations. Each branding can also be associated with specific entrypoints to apply the branding only on those ones mentioned in your plugin.xml file. RAPBranding.png
DrillDownAdapter Drilldown Adapters are a feature available for TreeViewers to help navigate through the data, instead of having to deal with ever expanding trees. In this way you can essentially zoom in to view just one part of the tree, i.e., drill down. Only two lines of code were added throughout the initialization of the viewer to invoke this feature in the context menu. Only one line was needed to add them to the view's toolbar. They are shown below:
// Create the Drill Down Adapter
drillDownAdapter = new DrillDownAdapter(viewer);

// Add the options to the view's toolbar (IToolBarManager)
drillDownAdapter.addNavigationActions(manager);

After adding them to the IToolbarManager of your view, they are looking like this:

RAPDrillDownAdapter.png

Editor framework The workbench implementation of RAP now really has support for the full editor infrastructure. Maybe there is one or the other little feature missing but it should work for the most situations where you need editor support. Note that we also support multi-page editors as you can see on the following screenshot:

RAPEditors.png

Thanks to the donation of a Fortune 500 corporation we were able to acquire additional resources to have editor support implemented for M5.

Support for opening/closing workbench parts You have now several possibilities to open a new view without initially defining it in your perspective. On the one side, you can use WorkbenchPage#showView("your.view.id") to show the view. All necessary data gets loaded from the server automatically.

Another way is - like you know it from the Eclipse Workbench - to use the "Show View" menu. To implement it in your RAP application, use ContributionItemFactory.VIEWS_SHORTLIST.create(IWorkbenchWindow); to get a list of all view shortcuts of the current perspective which can be used in a MenuManager. But don't forget to add the commonly used views as shortcuts to your perspective (see IPageLayout#addShowViewShortcut("your.view.id")).

For all the views without a shortcut, there is a "Other..." item appended to the end of the list to display the so loved "Show View" dialog where you can browse all available views. HINT: Now you can also categorize your views - just define the category attribute in your view extension.

RapShowViewDlg.png

Move extension points to org.eclipse.ui namespace To provide as much as possible reuse of RCP knowledge (and code) RAP provides now its workbench extension-points under the same namespace as the RCP workbench does. This is the second step of moving RAP to a subset of RCP regarding RCP-like functionality. Note that you must adjust your existing plugin.xml files like the example below:

RapExtensionPoint.png

Move package org.eclipse.ui.entrypoint to org.eclipse.ui.application Due to the efforts of making RAP-APIs a subset to RCP-APIs the package org.eclipse.ui.entrypoint has been renamed to org.eclipse.ui.application despite the fact that there is no need for implementing IPlatformRunnable as application definition. Please use the organize import functionality of the Eclipse IDE to adjust your existing source code.
Reexport of UI plug-ins The plug-in org.eclipse.rap.ui.workbench now reexports the basic UI plug-ins that are needed for RAP UI development. This is similar to RCP. The plug-in dependencies are org.eclipse.rap.w4t, org.eclipse.rap.rwt and org.eclipse.rap.jface.
Standalone Views The implementation of org.eclipse.ui.IPageLayout has been pursued. It is possible to add standalone views as shown in the code snippet below. The resulting perspective layout with the standalone view on the left hand side can be seen in the screenshot.

public class Perspective implements IPerspectiveFactory {

  public void createInitialLayout(IPageLayout layout) {
    String editorArea = layout.getEditorArea();
    layout.setEditorAreaVisible(false);
    layout.addStandaloneView(NavigationView.ID,  false, IPageLayout.LEFT, 0.25f, editorArea);
    IFolderLayout folder = layout.createFolder("messages", IPageLayout.TOP, 0.5f, editorArea);
    folder.addPlaceholder(View.ID + ":*");
    folder.addView(View.ID);
    layout.getViewLayout(NavigationView.ID).setCloseable(false);
  }
}

StandaloneView.png

Dynamic part informations You can now set specific part informations dynamically at runtime. This includes setPartName, setTitle and setTitleToolTip. Please use setPartName for setting the title of your view because setTitle is deprecated and only implemented for compatibility reasons. setContentDescription and setTitleImage are not yet available.
Minor usability improvement It's now possible to maximize/restore view parts by double-clicking on their corresponding TabItem.
Multiple Views We added a new method to open views multiple times. Requirement is that the view has the flag allowMultiple set to true. Just use the method showView(viewId, secondaryId, mode) of IWorkbenchPage to show additional instances of a view. Here is a little example:

  public void showAdditionalView(IWorkbenchWindow window) {
    try {
      window.getActivePage().showView(
                            "org.eclipse.rap.demo.DemoBrowserViewPart",
                            "two" ,
                            IWorkbenchPage.VIEW_ACTIVATE );
    } catch (PartInitException e) {
      e.printStackTrace();
    }
  }

RAPMultipleViews.png

IWorkbenchBrowserSupport The IWorkbenchBrowserSupport and IWebBrowser interfaces along with a default implementation that meets the minimal requirements have been added to the workbench. This allows you to open URLs in a popup window.

RapExternalBrowser.png

The corresponding extension points org.eclipse.ui.browser.browsers and org.eclipse.ui.browserSupport as provided by RCP are not yet available.

Support for ISharedImages There is now the possibility to get predefined images of the workbench by using the ISharedImages interface. The usage could look like this:
action.setImageDescriptor(PlatformUI.getWorkbench().getSharedImages().
				getImageDescriptor(ISharedImages.IMG_OBJS_INFO_TSK));
Views with local pulldown menus To use the local pulldown menu of your view, simply add the actions to the MenuManager of your ViewSite.
getViewSite().getActionBars().getMenuManager().add(yourAction);

In the end, this could look like this:

RAPViewMenu.png

Switch to RCP 3.3 With the switch to the RCP 3.3 codebase, there are many improvements on the workbench API. Additionally we now have a fully documented API based on the original javadoc of the Eclipse workbench. Another very nice feature is the support of the command and handler framework (see Platform Command Framework )
Automatic view toolbar arrangement If there is not enough space left in the TabFolder to show all the view actions, the toolbar is now automatically rearranged to use the full width of the folder.

Perspective extensions The RAP workbench offers you a new extension point: perspectiveExtensions. With this, you can contribute new views or view shortcuts to existing perspectives across several plug-ins. The extension point makes it easy to contribute additional views from other plug-ins to a perspective defined in your core UI plug-in.
Statusline support RAP now supports the StatusLine API. Note that the statusline is visible per default. To add e.g. actions to the statusline override the fillStatusLine of your ActionBarAdvisor:
  protected void fillStatusLine( final IStatusLineManager statusLine ) {
    statusLine.add( aboutAction );
  }

To hide the statusline use:

  public void preWindowOpen() {
    IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
    configurer.setShowStatusLine( false );
  [...]
Platform UI Error Handling To have an easy way to handle your exceptions during runtime, the Eclipse Platform introduced the Error Handling support. As this is an important part of every application, we now have this feature available in RAP. In order to let the workbench handle your exceptions, use something like the follow:
IStatus s = new Status(IStatus.ERROR, "org.demo", "This should not happen.", new NullPointerException());
StatusManager.getManager().handle(s, StatusManager.SHOW | StatusManager.LOG );

You can specify SHOW, LOG or both. With the SHOW style bit, a nice error dialog will pop up to inform the user about the exception.

RAPStatusHandler.png

The logfile of your application can be found in <working directory>/workspace/.metadata/.log where "working directory" is the directory you specified on the "Arguments" tab of your launch configuration.

Also see Platform UI Error Handling for more information on this topic.


Perspective Switcher Setting setShowPerspectiveBar( true ); of your IWorkbenchWindowConfigurer will result in something like this:

RAPPerspectiveSwitcher.png


ActionSets The RAP workbench has now two new extension points: actionSets and actionSetPartAssociations.

While the first one should be very familiar to RCP developers, the second one provides an infrastructure to bind your action sets to specfic workbench parts. This means you can active / deactive specfic action sets only for specfic parts. See also the extension point description for action sets and the actionSetPartAssociations.

Additionally you can contribute new action sets to existing perspectives with the help of perspectiveExtensions.

Progress Support The workbench now provides the progress API. Usage examples can be found in the demo plug-in at org.eclipse.rap.demo.actions.JobAction and org.eclipse.rap.demo.actions.JobActionWithDialog. You can find those actions in the RAP demo workbench in the Planning perspective.

Jobs.png

When using the progress API you should make sure to enable the ProgressIndicator in your WindowAdvisor:

     public void preWindowOpen() {
       IWorkbenchWindowConfigurer configurer = getWindowConfigurer();
       configurer.setShowProgressIndicator( true );
       ...

The standard progress view is also available, you can embed it into your application like this:

     <view
           class="org.eclipse.ui.ExtensionFactory:progressView"
           icon= "icons/pview.gif"
           id="org.eclipse.ui.views.ProgressView"
           name="Progress">
     </view>


Part Listener You've now the possibility to attach an IPartListener or IPartListener2 to a workbench page to stay informed about all part-related activities like when they're opened, closed, (de)activated or when they become hidden/visible.

Just use IPartService#addPartListener(IPartListener) as the following examples shows it:

IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
window.getActivePage().addPartListener(new IPartListener2() {

	public void partActivated(IWorkbenchPartReference partRef) {
		String partId = partRef.getId());
		// do something useful
	}

	...
});
DrillDownAdapter Drilldown Adapters are a feature available for TreeViewers to help navigate through the data, instead of having to deal with ever expanding trees. In this way you can essentially zoom in to view just one part of the tree, i.e., drill down. Only two lines of code were added throughout the initialization of the viewer to invoke this feature in the context menu. Only one line was needed to add them to the view's toolbar. They are shown below:
// Create the Drill Down Adapter
drillDownAdapter = new DrillDownAdapter(viewer);

// Add the options to the view's toolbar (IToolBarManager)
drillDownAdapter.addNavigationActions(manager);

After adding them to the IToolbarManager of your view, they are looking like this:

RAPDrillDownAdapter.png

Editor framework The workbench implementation of RAP now really has support for the full editor infrastructure. Maybe there is one or the other little feature missing but it should work for the most situations where you need editor support. Note that we also support multi-page editors as you can see on the following screenshot:

RAPEditors.png

RAP Forms

Forms Suppport There is initial support for the Forms Toolkit, Forms Editors and the like. The focus was put on API compatibility and functionality rather than mimicking the exact look of RCP Forms. The following is a list of the things that are already available:

  • ColumnLayout and TableWrapLayout
  • ExpandableComposite and Section
  • Hyperlink, ImageHyperlink (yet without actually showing the image) and HyperlinkGroup
  • TreeNode, Twistie and their common ancestor ToggleHyperlink
  • ScrolledPageBook
  • Form and ScrolledForm, FormToolkit
  • Form editors (FormEditor, FormPage, SharedHeaderFormEditor)

RAPFormsDemo.jpeg