Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
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 | + | 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 10: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).