blob: 6f9e28fbea13f3f16d230b0175d4423eb006354f [file] [log] [blame]
<h3>Fallback for Custom Themes</h3>
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.
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.
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="">bug 363736</a>.
<h3>Filtering Key Events for Widgets</h3>
The <code>RWT.ACTIVE_KEYS</code> constant has been
<a href = "">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 = "">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>.
<!-- TODO example -->
<h3>Suppressing Default Actions for Keys</h3>
<!-- RWT.CANCEL_KEYS allows to suppress default key event operations -->
The new constant <code>RWT.CANCEL_KEYS</code> can be used to specify a
<a href = "">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
Like <code>RWT.ACTIVE_KEYS</code>, this can be done either globally, using
<code>Display.setData()</code>, or on a
<a href = "">per-widget base</a>
using <code>Widget.setData()</code>.
For more details, see the JavaDoc on <code>RWT.CANCEL_KEYS</code>.
<h3>Discontinued Support for doit-flag on Key Events</h3>
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 = "">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 -->
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.
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 = "">several issues</a>
<a href = "">missing events</a> or
<a href = "">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.
<h3>Content Proposal Improvements</h3>
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.
<img class="framed" src="images/ContentProposal.png" />