Here are some of the more noteworthy things available in the first release build (October 10, 2007) which is now available for download.
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. |
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.
|
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.
|
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 If a table is created with the 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:
|
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.
Additionally if there is not enough space to wrap the CoolItems a chevron will be visible to have access to the invisible items.
|
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:
group.frame.border: 3 double #56a0ea group.label.font: 12 bold Arial, Helvetica, sans-serif ... button.background: #9dd0ea button.border: 2 #1695d4 ...
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
|
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.
|
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 TableItem s.
Multi-selection can now be enabled by passing the Except for
|
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. |
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 If a table is created with the 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 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.
|
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. |
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 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 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
|
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.
>>> |
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.
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:
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".
|
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.
>>> |
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:
|
Dialogs | RAP JFace now includes the base classes to implement dialogs like Window, WindowManager, Dialog, and IconAndMessageDialog and provides the most often used dialogs.
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 |
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. |
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:
|
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:
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 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
|
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:
|
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); } }
|
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(); } } |
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.
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:
|
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.
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:
|
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 |
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.
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 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:
|
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:
|
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:
|