Jump to: navigation, search

5 Display

Back to RWTOverview

Display

The display represents the client side browser window. All shells that belong to a display reside in one browser window.

The display creation in RWT is slightly different than in SWT. Instead of a main method RWT provides the IEntryPoint Interface in its createUI method. In this method you need to implement the creation of the display and the initial set of widgets to be displayed.

 public class Example implements IEntryPoint {
   public Display createUI() {
     Display display = new Display();
     final Shell shell = new Shell( display, RWT.NONE );
     shell.setBounds( 10, 10, 800, 600 );
   
     ToolBar toolBar = new ToolBar( shell, RWT.NONE );
     ToolItem item1 = new ToolItem( toolBar, RWT.PUSH );
   
     ...
   
     shell.layout();
     shell.open();
     return display;
   }
 }

Naming Your Application

Not yet implemented. The HTML title could be used to mimic a minimal application naming.

Display Life Cycle

Similar, but the display lives as long as the browser session is active.

Events and Listeners

Will be implemented.

Event Filters

Not yet implemented. Quote SWT book: "Filters are Powerful and Dangerous". One of the standard use cases for event filtering - large numbers of events - are not a good idea for RWT because of the distributed nature of RAP (and associated network latency).

Runnable "Execs"

Not yet implemented.

The Event Loop

Not applicable. We have request / response cycles instead. Please see also the thread topic directly below.

Multithreaded Programming

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;
  }

Enabling the UICallBack mechanism will result in a http response that is kept open / alive as long as the background thread is executing (so called Comet).

Threading requires extra care as we are executing the threads on a server!

Timers

Not yet implemented.

Putting It All Together: Multithreading, Timers, Events, and the Event Loop

  • Events are generated by the user and read and dispatched to widgets by the the thread that services the request.
  • Application code registers interest in events by adding event listeners to widgets. ...
  • If the user interface thread is busy (in our case a request has not received its response) further events are queued (on the client side).
  • pushing UI updates to the user by calling a method like readAndDispatch() is not possible
  • no timers yet ;-)

Monitors, Bounds, and Client Area

  • Very likely no Monitors ...
  • Bounds / Client Area - implemented as the size of the browser window

The Active Shell, All Shells, and Focus Control

Not yet implemented

Cursor Control and Location

Very unlikely to be implemented.

Display Depth and DPI

Sorry, but no;-)

Updating the Display

Updating the Display is not an issue in RWT. At the end of the request life cycle all changes are 'rendered' and sent to the client.

Application Data

Not yet implemented, but will work as in SWT.

Coordinate Mapping and Mirroring

Not yet fully implemented, but will work as in SWT. Please note that to fully support bidirectional languages there has more to be done than mirroring and it is yet unclear if we can realize this client-side.

Miscellaneous

  • Beep: no :(
  • Double-Click Time: depends on the JavaScript library (http://qooxdoo.org) we are using on the client side.