noteworthy/1.5/_news-R.html

<div>

  <h2>Applications / Framework</h2>

  <h3>ApplicationConfiguration API</h3>

  <p>
    We introduced a new API to configure and start RAP applications programmatically.
    This is an alternative to registering application entrypoints, themes, etc. as extensions.
    With this new API it is now possible to write very write lightweight applications that do not
    depend on the Eclipse UI stack (<code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>ui*</code>) or the
     the Equinox extension registry.
  </p>
  <p>
    To configure an application, implement the new interface
    <code>org.<wbr/>eclipse.<wbr/>rwt.<wbr/>engine.<wbr/>ApplicationConfiguration</code>:
  </p>
  <pre>
public class SimpleConfiguration implements ApplicationConfiguration {

  public void configure( Application application ) {
    application.addEntryPoint( &quot;/simple&quot;, SimpleEntryPoint.class, null );
    application.addEntryPoint( &quot;/other&quot;, AnotherEntryPoint.class, null );
    application.addServiceHandler( &quot;custom.id&quot;, new MyServiceHandler() );
    ...
  }
}
</pre>
  <p>
    An application can be started programmatically using an <code>ApplicationRunner</code>:
  </p>
  <pre>
ApplicationConfiguration configuration = new SimpleConfiguration();
ApplicationRunner runner = new ApplicationRunner( configuration, servletContext );
runner.start();
</pre>
  <p>
    ... or registered as an OSGi service (see below).
  </p>

  <h3>OSGi Integration</h3>

  <p>
    A new bundle <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>rwt.<wbr/>osgi</code> has been introduced
    that integrates RAP with OSGi.
    This bundle is now required for every RAP application in an OSGi environment, including
    applications that use the Eclipse workbench.
  </p>
  <p>
    When an <code>ApplicationConfiguration</code> is registered as an OSGi service, the rwt.osgi
    bundle will auto-start an application with this configuration.
    By default, the application is started in the root context path.
    Using a service property, a custom context path can be selected.
    The name of this service property is kept in the constant
    <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>rwt.<wbr/>osgi.<wbr/>ApplicationLauncher.<wbr/>PROPERTY_CONTEXT_NAME</code>.
  </p>
  <p>
    Here's an example of an application configuration registered as a declarative service using the
    context path <em>example</em>:
  </p>
  <pre>
&lt;scr:component xmlns:scr=&quot;http://www.osgi.org/xmlns/scr/v1.1.0&quot;&gt;
  &lt;implementation class=&quot;com.example.SimpleConfiguration&quot;/&gt;
  &lt;service&gt;
     &lt;provide interface=&quot;org.eclipse.rwt.application.ApplicationConfiguration&quot;/&gt;
  &lt;/service&gt;
  &lt;property name=&quot;contextName&quot; type=&quot;String&quot; value=&quot;example&quot;/&gt;
&lt;/scr:component&gt;
</pre>
  <p>
    Alternatively, applications can also be started programmatically using the
    <code>ApplicationLauncher</code>, which is made available as a service by the rwt.osgi bundle.
  </p>
  <pre>
ApplicationLauncher launcher = <em>... (acquire from service)</em>
HttpService httpService = <em>... (acquire from service)</em>
launcher.launch( configuration, httpService, httpContext, contextName, contextDirectory );
</pre>

  <h3>Simplified RWT Startup</h3>

  <p>
    RWT applications are now also configured using the new ApplicationConfiguration API.
    The former init parameters have been replaced by one parameter that accepts the fully qualified
    class name of an <code>ApplicationConfiguration</code> implementation.
    The name of this init parameter is kept in the constant
    <code>ApplicationConfiguration.<wbr/>CONFIGURATION_PARAM</code>.
    Here's an exemplary web.xml snippet:
  </p>
  <pre>
&lt;context-param&gt;
  &lt;param-name&gt;org.eclipse.rap.applicationConfiguration&lt;/param-name&gt;
  &lt;param-value&gt;com.example.ExampleConfiguration&lt;/param-value&gt;
&lt;/context-param&gt;
&lt;listener&gt;
  &lt;listener-class&gt;org.eclipse.rwt.engine.RWTServletContextListener&lt;/listener-class&gt;
&lt;/listener&gt;
</pre>
  <p>
    The <code>RWTServletContextListener</code> needs to be registered so that RWT is notified when
    the servlet context is created.
    For more information, check the
    <a href="http://eclipse.org/rap/developers-guide/">developer's guide</a>.
  </p>

  <h3>EntryPoint Parameters</h3>

  <p>
    Some properties of the application, such as the theme, the page title, or the favicon, can
    already be customized in a branding extension.
    The new ApplicationConfiguration API provides a more general concept for those customizations,
    accepting a simple property map for entry points.
    The property names for the default web client are defined by the new class
    <code>org.<wbr/>eclipse.<wbr/>rwt.<wbr/>client.<wbr/>WebClient</code>.
    Other client implementations can provide their own properties.
    Here's an example how to use it:
  </p>
  <pre>
Map&lt;String, String&gt; properties = new HashMap&lt;String, String&gt;();
properties.put( WebClient.THEME_ID, &quot;com.example.mytheme&quot; );
properties.put( WebClient.FAVICON, &quot;images/favicon.png&quot; );
application.addEntryPoint( &quot;/example&quot;, entryPointFactory, properties );
</pre>

  <h3>EntryPoints by Path</h3>

  <p>
    So far, entrypoints have been registered with a <em>name</em> and have been available at a URL
    like this:
  </p>
<pre>
http://hostname/context/rap?startup=<em>&lt;entryPointName&gt;</em>
</pre>
  <p>
    Both, the servlet name “rap” and the parameter name “startup” were hard-coded in RWT.
    A branding had to be used to map the entrypoint to a custom URL.
    Now, the extension point <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>ui.<wbr/>entrypoint</code>
    supports a new attribute <code>path</code> that allows to register an entrypoint for a given
    path:
  </p>
  <pre>
&lt;extension
    point=&quot;org.eclipse.rap.ui.entrypoint&quot;&gt;
  &lt;entrypoint
      id=&quot;org.example.exampleEntryPoint&quot;
      class=&quot;org.example.ExampleEntryPoint&quot;
      path=&quot;/example&quot; /&gt;
&lt;/extension&gt;
</pre>
  <p>
    This example shows how an entrypoint is registered for the path <em>/example</em>.
    The application will be available at:
  </p>
<pre>
http://hostname/context/example
</pre>
  <p>
    This method is encouraged and meant to replace the registration using a parameter.
    Also with the new <code>ApplicationConfiguration</code> API, entrypoints are registered by path.
  </p>

  <h3>New Operation Mode for JEE Compatibility</h3>

  <p>
    In order to provide full compatibility to SWT, the SWT threading model has to be emulated very
    closely.
    To make this possible, RWT starts a separate UI thread for every user session and executes all
    application code in this thread by default.
    This carries the consequence that application code cannot directly access JEE transaction or
    security contexts, which are only available on the original request thread.
  </p>

  <p>
    However, this exact compatibility to SWT is only required by code that uses SWT's few blocking
    APIs.
    The most obvious case are blocking dialogs (i.e. calling dialog.open() will suspend code
    execution until the dialog is closed by the user, and then return a value).
    The Eclipse workbench needs full SWT compatibility, but most other applications benefit from
    a simple, lightweight operation mode that does not start these separate threads.
    Instead of using the blocking APIs, those applications can use a callback pattern.
  </p>

  <p>
    To support those lightweight applications, RWT now has two exchangeable <em>operation modes</em>
    called <em>SWT compatibility</em> and <em>JEE compatibility</em>.
    The JEE compatibility mode is encouraged for new applications that do not use the workbench,
    because it is simpler, consumes less server resources and complies with the requirements of JEE.
    It is also the default for applications using the new ApplicationConfiguration API.
    The operation mode can be configured in the ApplicationConfiguration:
  </p>
<pre>
public void configure( Application application ) {
  application.setOperationMode( OperationMode.SWT_COMPATIBILITY );
  ...
}
</pre>
  <p>
    An important consequence of the new JEE compatibility mode is that the method
    <code>Display.sleep()</code> is not supported.
    Applications must omit the SWT main loop in the entrypoints.
  </p>
  <p>
    Applications that are started using extension points always run in the SWT compatibility
    mode.
  </p>
  <p>
    For more detailed information, please check the
    <a href="http://eclipse.org/rap/developers-guide/">developer's guide</a>.
  </p>

  <h3>Failover and Clustering Support</h3>

  <p>
    With the new JEE compatible mode, RWT also supports transparent session failover.
    This enables RWT standalone applications to run in a high-availability cluster.
  </p>
  <p>
    In order to replicate sessions between cluster nodes, all classes in RWT whose instances will
    have session scope are now serializable.
    Note that application code must also be prepared for clustering by making all objects that live
    in the session scope serializable.
  </p>
  <p>
    Serializable RWT sessions can also be used to swap inactive sessions onto disk and thereby
    releasing the memory consumed by them. This allows for infinite session timeout settings
    and saves users from annoying 'the session has timed out' messages.
  </p>
  <p>
    Clustering of OSGi applications is not yet supported.
    For further details, please check the
    <a href="http://wiki.eclipse.org/RAP/RWT_Cluster">Cluster wiki page</a>.
  </p>

  <h2>Network / Communication</h2>

  <h3>New Client/Server Protocol</h3>

  <p>
    The communication between server and client has been replaced with a new, JSON-based format.
    With this new protocol, RAP now provides for exchangeable client implementations.
    RAP clients can be developed in any language and for any platform.
    The new protocol also makes the responses much more readable and eases debugging.
  </p>
  <p>
    <img class="framed" src="images/Firebug-JSON.png" />
  </p>
  <p>
    The exact format is described in the
    <a href="http://wiki.eclipse.org/RAP/Protocol">RAP Protocol wiki page</a>.
  </p>

  <h3>UICallback Improvements</h3>

  <p>
    The UI callback was redesigned and made more robust.
  </p>
  <p>
    When a callback request fails, the client sends a new callback request to re-establish
    the broken callback connection. To avoid unnecessary load on the client, retry requests
    are sent with a suitable delay.
  </p>
  <p>
    On some servlet engines, an active UI callback prevented the session from expiring. This
    has been solved so that applications can activate the UI callback without interfering
    with the session timeout.
  </p>
  <p>
    The <a href="http://wiki.eclipse.org/RAP/UI_Callback">Server Push wiki page</a>
    summarizes how the mechanism works internally.
  </p>

  <h2>Target Platform Changes</h2>

  <h3>q07 Fragment removed</h3>

  <p>
    The fragment <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>rwt.<wbr/>q07</code> is no longer needed
    and has been removed.
    The contents have been merged into the <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>rwt</code>
    bundle.
  </p>
  <p>
    The q07 fragment had originally been introduced to be able to support different versions of
    the qx client library. Meanwhile, we decided to maintain and evolve our own copy of this
    client library
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=320993">bug 320993</a>),
    so the fragment is not needed anymore.
    Moreover, the new protocol provides a more flexible way to support alternative clients.
  </p>

  <h3>New rwt.osgi Bundle</h3>

  <p>
    The RWT OSGi integration bundle <code>org.<wbr/>eclipse.<wbr/>rap.<wbr/>rwt.<wbr/>osgi</code>
    has been added to the RAP runtime.
    Please remember to include this bundle in your configuration for all OSGi-based applications.
  </p>

  <h3>Eclipse 4.2</h3>

  <p>
    The RAP 1.5 target platform is based on Eclipse 4.2 (Juno).
    However, RAP does not yet provide an integration with the 4.2 workbench.
    The RAP implementation of the Eclipse workbench is still based on 3.x.
  </p>
  <p>
    There are a couple of important changes to the target platform.
  </p>

  <ul>
    <li>
      The target now contains the <strong>Servlet 3.0</strong> API.
      Although the <code>javax.<wbr/>servlet</code> bundle has a 3.0 version, it exports packages
      as version 2.6.0 to comply with the OSGi versioning rules
      (see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245">bug 360245</a>).
    </li>
    <li>
      The target platform includes <strong>Jetty 8</strong> instead of Jetty 6.
      This is not just a change of the version number, also the package names have changed
      from <code>org.mortbay.jetty</code> to <code>org.eclipse.jetty</code>.
      Since the Jetty project decided to split their code into smaller modules
      there are now seven Jetty bundles required instead of two.
    </li>
    <li>
      The platform now includes a new OSGi console based on the Apache <strong>Felix Gogo</strong>
      project.
      Therefore, the basic target platform for RAP applications now contains three more bundles
      from Apache Gogo
      (<code>org.<wbr/>apache.<wbr/>felix.<wbr/>gogo.*</code>) to support it.
    </li>
  </ul>
  <p>
    Please adapt your launch configurations to these changes as needed.
  </p>

  <h3>Runtime Feature Split</h3>

  <p>
    The runtime repository now contains two different features:
    The first one contains all bundles provided by the RAP project.
    The other feature provides a selection of bundles from the Juno platform that are
    required for a complete RAP target platform.
    If you want to create a simple RAP target platform, you'll need both.
  </p>
  <p>
    This split will make it easier to work with mixed targets.
    If you already have the Equinox Core SDK and Jetty, you'll only need to add RAP itself.
    This way, you prevent duplicate bundles in your target platform.
  </p>

  <h2>Widget Set</h2>

  <h3>Shared JavaScript Implementation of Tree and Table</h3>

  <p>
    Tree and Table are now using the same JavaScript implementation on the client. This allowed us
    to fix a lot of <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=332524#c0">bugs</a> and
    gave the Table a small performance boost. It also makes it very easy for us to always enable new
    features for both widges on the same time, like fixed columns and markup.
  </p>

  <h3>Markup Support</h3>

  <p>
    For a selection of widgets, simple HTML markup is now accepted in the <code>setText()</code>
    method. Currently supported widgets are <code>TableItem</code>, <code>TreeItem</code>, 
    <code>List</code>, <code>Label</code> and <code>CLabel</code>.
  </p>
  <p>
    <img class="framed" src="images/Markup-Table.png" />
  </p>
  <p>
    To enable markup support for a widget, use the new constant
    <code>RWT.MARKUP_ENABLED</code> in the <code>setData()</code> method.
    This must be done directly after creating the widget and cannot be changed later.
    Here's a code example:
  </p>
  <pre>
Table table = new Table( parent, SWT.BORDER );
table.setData( RWT.MARKUP_ENABLED, Boolean.TRUE );
TableItem item = new TableItem( table, SWT.NONE );
item.setText( &quot;Some &lt;em&gt;text&lt;/em&gt; with &lt;strong&gt;markup&lt;strong&gt;&quot; );
</pre>
  <p>
    The markup will be validated on the server. Currently, the following HTML elements
    area allowed:
  </p>
  <ul>
    <li>
      most <strong>inline elements</strong> like
      <code>&lt;em&gt;</code>,
      <code>&lt;strong&gt;</code>,
      <code>&lt;big&gt;</code>,
      <code>&lt;small&gt;</code>,
      <code>&lt;sup&gt;</code>,
      <code>&lt;sub&gt;</code>,
      <code>&lt;del&gt;</code>,
      <code>&lt;ins&gt;</code>, etc.
    </li>
    <li>
      <strong>linebreaks</strong>
      using <code>&lt;br/&gt;</code>
    </li>
    <li>
      <strong>images</strong>:
      <code>&lt;img src=&quot;images/example.png&quot; width=&quot;16&quot; height=&quot;16&quot; /&gt;</code>,
      width and height are obligatory
    </li>
    <li>
      <strong>links</strong> like
      <code>&lt;a href=&quot;http://eclipse.org&quot;&gt;Eclipse&lt;/a&gt;</code>.
      To open the linked page in a new tab, you can use the <code>target</code>
      attribute.
    </li>
  </ul>
  <p>
    See the JavaDoc for <code>RWT.MARKUP_ENABLED</code> for further information.
    You can try it out in our updated demo on the
    <a href="http://rap.eclipsesource.com/rapdemo/examples#rich-label">Rich Labels</a> page.
    Check out the
    <a href="http://rap.eclipsesource.com/rapdemo/examples#table-markup">Table with markup</a>
    page as well.
  </p>

  <h3>Custom Item Height</h3>

  <p>
    When you use markup in a Table or a Tree, you may want to set a fixed item height manually.
    To do so, you can use the new <code>setData()</code> constant
    <code>RWT.CUSTOM_ITEM_HEIGHT</code>:
  </p>
  <pre>
table.setData( RWT.CUSTOM_ITEM_HEIGHT, Integer.valueOf( 62 ) )
</pre>
  <p>
    A custom item height must be set directly after creating the widget and cannot be changed
    later.
  </p>

  <h3>Virtual Tree</h3>

  <p>
    The server-side part of the Tree widget was considerably improved and optimized. Now,
    a Tree with SWT.VIRTUAL style can handle huge item counts without performance degradation.
  </p>
  <p>
    For a live demo, check out the tab called <em>Complex Data</em> in our
    <a href="http://rap.eclipsesource.com/">Examples demo</a>.
  </p>

  <h3>Fixed Table Columns</h3>

  <p>
    It's now possible to exclude a given number of leftmost table columns from horizontal
    scrolling.
    This is very useful for tables that have a lot of columns, with the first column(s)
    containing some kind of heading or key value (e.g. a person's name) that should always be
    visible.
  </p>
  <p>
    <img class="framed" src="images/FixedColumns.png" />
  </p>
  <p>
    For more details, see the JavaDoc on <code>RWT.FIXED_COLUMNS</code>.
  </p>

  <h3>Multiline Headers for Tree and Table</h3>

  <p>
    <img class="framed" src="images/MultilineHeaders.png" />
  </p>
  <p>
    <code>TableColum</code> and <code>TreeColumn</code> now respect line breaks.
    No special setting is required. When the text of a header contains a linebreak character
    (<code>\n</code>), the line break will be rendered and the column height will be adjusted
    automatically.
  </p>

  <h3>Non-blocking Script Evaluation for Browser</h3>

  <p>
    The <code>Browser</code> widget provides two methods to execute JavaScript,
    <code>execute()</code> and <code>evaluate()</code>.
    Both methods are blocking and won't work with the new <code>JEE_COMPATIBILITY</code> mode.
  </p>
  <p>
    Therefore, a new utility class <code>BrowserUtil</code> has been introduced to evaluate
    JavaScript in a Browser widget in a non-blocking way.
    Instead of waiting for the script to be executed, you provide a
    <code>BrowserCallback</code> implementation that will be notified when the evaluation has
    completed:
  </p>
  <pre>
Browser browser = new Browser( parent, SWT.NONE );
...
BrowserUtil.evaluate( browser, script, new BrowserCallback() {
  public void evaluationSucceeded( Object result ) {
  }
  public void evaluationFailed( Exception exception ) {
  }
} );
</pre>

  <h3>Arrow Buttons</h3>

  <p>
    Finally, we support the <code>SWT.ARROW</code> style flag for <code>Button</code>.
    This style is used together with one of <code>SWT.TOP</code>, <code>SWT.BOTTOM</code>,
    <code>SWT.LEFT</code>, or <code>SWT.RIGHT</code> to create buttons with an arrow symbol.
  </p>
  <p>
    <img class="framed" title="Arrow Buttons in RAP" src="images/ArrowButtons.png" />
  </p>
  <p>
    Of course, the style of arrow buttons can be configured in a theme:
  </p>
  <pre>
Button[ARROW] {
  border: 1px solid #bdbdbd;
  padding: 10px;
}

Button-ArrowIcon[UP] {
  background-image: url( theme/images/arrow-up.png );
}
</pre>

  <h2>Event System</h2>

  <h3>Filtering Key Events for Widgets</h3>

  <p>
    The <code>RWT.ACTIVE_KEYS</code> constant has been
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=343248">introduced in RAP 1.4</a>
    to allow for key bindings.
    Now this constant can also be used to limit the keys that will trigger a key event on a
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=346597">single widget</a>.
    This means that when a key-listener is attached to a widget,
    it's now possible to choose beforehand which keys will trigger events.
    This can drastically reduce the traffic caused by key-events.
    For more details, see the JavaDoc on <code>RWT.ACTIVE_KEYS</code>.
  </p>
  <!-- TODO example -->

  <h3>Suppressing Default Actions for Keys</h3>
  <!-- RWT.CANCEL_KEYS allows to suppress default key event operations -->

  <p>
    The new constant <code>RWT.CANCEL_KEYS</code> can be used to specify a
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=367079">list of keys to be cancelled</a>.
    Instead of dynamically cancelling events by setting the <code>doit</code>-flag to
    <code>false</code> in a <code>KeyListener</code>, this allows to do the same thing in a
    static way.
    When CANCEL_KEYS are defined, this will suppress the default operation associated with these
    keys, e.g. changing focus on <code>TAB</code> or closing a popup with <code>ESC</code>.
    Note that some browser shortcuts can not be suppressed, like changing the browser tab with
    CTRL+TAB.
  </p>
  <p>
    Like <code>RWT.ACTIVE_KEYS</code>, this can be done either globally, using
    <code>Display.setData()</code>, or on a
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=367869">per-widget base</a>
    using <code>Widget.setData()</code>.
    For more details, see the JavaDoc on <code>RWT.CANCEL_KEYS</code>.
  </p>

  <h3>Discontinued Support for doit-flag on Key Events</h3>

  <p>
    We decided to replace the support for dynamically vetoing key and traverse events
    in favor of the static approach described above.
    With this change, setting the <code>doit</code>-flag on <code>KeyEvent</code>s and
    <code>TraverseEvent</code>s has
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=367871">no longer any effect</a>
    in RAP.
    As a replacement, the <code>RWT.CANCEL_KEYS</code> constant should be used.
    JFace cell editors have already been adapted to this change.
    <!-- TODO custom navigation strategies -->
  </p>
  <p>
    We've introduced <code>KeyEvents</code> and <code>TraverseEvents</code> in RAP 1.2 to be
    able to support JFace cell editors.
    There were multiple issues remaining that we could never overcome,
    such as synchronous HTTP requests not working correctly in some browsers,
    or security-restrictions for certain keys for in others.
    Over time, we've realized that dynamically preventable key and traverse events are not
    going to work fully and reliably in all browser.
  </p>
  <p>
    We dislike taking functionality away, but in this case we are convinced that the
    improvements are more valuable than the loss.
    We were able to heavily improve the key event handling and to fix
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=367091">several issues</a>
    regarding
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=329639">missing events</a> or
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=366788">wrong values</a>.
    The change also allowed us to send key events in asynchronous HTTP requests
    <em>in all browsers</em>, making the client UI more responsive.
  </p>

  <h2>Theming</h2>

  <h3>New Default Theme</h3>

  <p>
    RAP 1.5 got a new default look.
    The new theme aims at bringing a modern, decent look into RAP applications with more white 
    space and subtle usage of roundings, shadows and gradients. To achieve this, the 
    themability of many RWT widgets has been extended by adding missing CSS properties.
  </p>
  <p>
    <img class="framed" src="images/NewTheme-Dialog.png" />
    <img class="framed" src="images/NewTheme-Form.png" />
  </p>

  <h3>Fallback for Custom Themes</h3>

  <p>
    The RAP default theme is now an equitable theme, and it is no longer used as a fallback for
    custom themes.
    Instead of the default theme, all theming properties now have a default value which is used
    as a fallback in case the theme does not define a value for this property.
  </p>
  <p>
    Unlike the RAP default theme, these fallback values will not change.
    They are chosen to be plain values without any effects, i.e. no gradients, rounded borders,
    or shadows, just plain black-and-white.
    With this change, custom themes will be more stable.
    Changes to the RAP default theme will not affect custom themes anymore.
  </p>
  <p>
    The default values are still defined in the respective
    <code>&lt;Widget&gt;.default.css</code> files, and the RAP default theme is now contained
    in a file of its own.
    For details, see
    <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=363736">bug 363736</a>.
  </p>

  <h3>Text Shadows</h3>

  <p>
    The Theming now supports text shadows for most widgets that display text:
    Shell, Label, CLabel, CTabFolder, Button, DateTime, ExpandBar, Group, Link,
    List, Spinner, TabFolder, Menu, ToolTip, Combo, CCombo, Tree, Table, Text, and ToolBar
  </p>
  <p>
    <img class="framed" title="Text Shadows in RAP" src="images/Text-Shadows.png" />
  </p>
  <p>
    Text shadows are not available in Internet Explorer due to this browser's lack of support
    for this feature.
    Transparency for text shadows is supported using the
    <a href="http://www.w3.org/TR/css3-color/#rgba-color">rgba</a> notation for color.
    Example:
  </p>
  <pre>
Button {
  text-shadow: 0 1px 0 rgba( 0, 0, 0, 0.3 );
}</pre>

  <h3>New Animations</h3>

  <p>
    The theming for <code>Shell</code> and <code>Composite</code> now supports these additional
    animations:
  </p>
  <p>
    <code>flyInTop</code>, <code>flyInRight</code>, <code>flyInBottom</code>, <code>flyInLeft</code>,<br/>
    <code>flyOutTop</code>, <code>flyOutRight</code>, <code>flyOutBottom</code>, <code>flyOutLeft</code>
  </p>
  <p>
    In addition, <code>Composite</code> now also supports
    <code>fadeIn</code>, <code>fadeOut</code>, <code>slideIn</code>, and <code>slideOut</code>.
  </p>
  <p>
    The animations are shown when the widget either appears or disappears, respectively.
    Since the widget's children are animated together with its parent, it's now possible to
    animate any widget by placing it in a Composite.
    It should be noted that the animations may not run smoothly in older browsers, or when the
    Shell/Composite is very bulky.
    Using fadeIn/Our or slideIn/Out in IE7 or 8 can cause minor rendering glitches during the
    animation, depending on the contained widgets and their theming.
  </p>

  <h3>FileUpload Theming</h3>

  <p>
    The FileUpload widget is no longer bound to the theming of the <code>Button</code> theming
    but can be styled separately.
    All CSS properties that are supported for <code>Button</code> are now also supported for the
    new <code>FileUpload</code> CSS element.
  </p>

  <h2>Browser Support</h2>

  <h3>Improved Internet Explorer 9 Support</h3>

  <p>
    Internet Explorer 9 was a significant improvement over previous versions, finally catching
    up to other browsers regarding performance and compatibility.
    RAP can now fully utilize all its new features (HTML5, CSS3, SVG) by switching to standard
    rendering in IE9 (as opposed to quirksmode used for previous IE versions).
    This gives RAP applications a noticeable performance-boost in IE9, especially when using GC
    for drawing complex graphs.
  </p>

  <h3>Discontinued Internet Explorer 6 Support</h3>

  <p>
    As technology marches on, we also decided to no longer officially support IE6 in RAP 1.5.
    RAP 1.4 will continue to support it.
  </p>

  <h2>JFace</h2>

  <h3>Content Proposal Improvements</h3>

  <p>
    The key event fixes mentioned above also allowed us to repair our
    <code>ContentProposalAdapter</code> implementation.
    Now we can provide a fully functional content proposal that can be operated completely by
    the keyboard on all browsers.
    Combined with the <code>RWT.ACTIVE_KEYS</code> constant, the requests can be limited to
    those needed for opening the content proposal.
  </p>
  <p>
    <img class="framed" src="images/ContentProposal.png" />
  </p>

  <h2>RAP Project</h2>

  <h3>Source Code Moved to Git, Mirrored on GitHub</h3>

  <p>
    Our source code has moved from CVS to Git.
    The CVS still exists but is now read-only.
    If you used to work with RAP source code from CVS, check the
    <a href="http://eclipse.org/rap/source">source code</a> page for the new repository URLs.
    Mirrors of the rap repositories are also available on
    <a href="https://github.com/eclipse/">GitHub</a>.
  </p>

  <h3>Public Nightly Builds</h3>

  <p>
    With RAP 1.5, all software is built on the
    <a href="https://hudson.eclipse.org/hudson/">Eclipse foundation's Hudson server</a>.
    Nightly builds are available in a public repository.
    The details can be found on the <a href="http://eclipse.org/rap/downloads/">downloads page</a>.
  </p>

  <h3>Developer Guide Online</h3>

  <p>
    To help developers finding up-to date information on RAP, we provide the latest version of
    the developer's guide on our <a href="http://eclipse.org/rap/developers-guide/">project website</a>.
  </p>

</div>