Jump to: navigation, search

Difference between revisions of "RAP/RWT"

< RAP
 
(A new Widget Toolkit API)
Line 1: Line 1:
 
== A new Widget Toolkit API==
 
== A new Widget Toolkit API==
  
This place is inteded to host the discussion related to a new widget API for RAP [http://eclipse.org/rap]. Please see also bug #158930 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=158930]
+
This place is inteded to host the discussion related to a new widget API for [http://eclipse.org/rap RAP]. Please see also [https://bugs.eclipse.org/bugs/show_bug.cgi?id=158930 bug #158930]
 +
 
 +
An issue that is partly related to the API question are LayoutManagers.
 +
 
 +
'''Why a new API at all?'''
 +
* Low level (web) technologies should be hidden from the targeted developers (e.g. there should not be a WebComponent#getStyle() method to modify css styles directly)
 +
* Layout algorithms are too basic to build a workbench upon.
 +
 
 +
'''Use the [http://eclipse.org/swt SWT] API?'''
 +
 
 +
'''Pro:'''
 +
* Full binary compatibility
 +
* Complete reuse of JFace
 +
'''Contra:'''
 +
* SWT with its comprehensive set of widgets, 'dictates' the intial implementation effort. With another API we could start with a smaller subset of widgets.
 +
* Hides the semantic differences between a client-side only and a distributed environment. E.g. it would be possible to implement a KeyListener, but since the event must go over the wire the user experience would be low.
 +
* Probably won't meet the high expectations of RCP developers
 +
* It is yet unclear how close we can get to the 'original' layout managers. From what we know by now a big challenge would be to compute the actual size of text (as used to determine the prefered size of a widget)
 +
 
 +
'''Use an SWT-like API?'''
 +
 
 +
To escape the downside of emulating the full SWT API, we could use a subset of SWT (like [eRCP http://www.eclipse.org/ercp]) and provide alternative/additional API where SWT does not meet the requirements of a distributed environment (in particular event handling).

Revision as of 09:27, 27 September 2006

A new Widget Toolkit API

This place is inteded to host the discussion related to a new widget API for RAP. Please see also bug #158930

An issue that is partly related to the API question are LayoutManagers.

Why a new API at all?

  • Low level (web) technologies should be hidden from the targeted developers (e.g. there should not be a WebComponent#getStyle() method to modify css styles directly)
  • Layout algorithms are too basic to build a workbench upon.

Use the SWT API?

Pro:

  • Full binary compatibility
  • Complete reuse of JFace

Contra:

  • SWT with its comprehensive set of widgets, 'dictates' the intial implementation effort. With another API we could start with a smaller subset of widgets.
  • Hides the semantic differences between a client-side only and a distributed environment. E.g. it would be possible to implement a KeyListener, but since the event must go over the wire the user experience would be low.
  • Probably won't meet the high expectations of RCP developers
  • It is yet unclear how close we can get to the 'original' layout managers. From what we know by now a big challenge would be to compute the actual size of text (as used to determine the prefered size of a widget)

Use an SWT-like API?

To escape the downside of emulating the full SWT API, we could use a subset of SWT (like [eRCP http://www.eclipse.org/ercp]) and provide alternative/additional API where SWT does not meet the requirements of a distributed environment (in particular event handling).