Erland Isaksson edited this page Dec 31, 2015 · 1 revision


Please note that the RCP Client prototype is no longer maintained, we have moved it our of the prototype structure into a regular module called Yggdrasil.


A first RCP client is available in the prototype directory, the source can be found here:

Brief instructions on what you need to do to get it running is available in the Readme-file:

Latest pre-compiled nightly builds of RCP Client can be found here:


This section provides a very rough overview of things to do. For details, please refer to the shared "todo list".

Here are a few words on what I think needs to be done to bring this thing out of the prototype folder and let us start widening scope and honing details:

  1. (done: Move out of prototype folder, rename to Yggdrasil.)
  2. (done: Restructured plug-ins (as outlined in below))
  3. A bootstrap to deploy the basic client (e.g. JWS)
  4. An update site where we can upload new versions of the plug-ins
  5. (done: Create extension points to allow more editors)

Effective time, this would all take a couple of weeks or so. Working odd hours around midnight ... I'm not so sure :-(

Design Guidelines

Some brief and preliminary thoughts on the design principles for the RCP client. Comments expected and welcome!

  • JFace
    • JFace offers a convenience layer on top of SWT, making it much easier to work with. Application code should rarely touch an SWT component directly.
    • JFace data binding is perhaps the most important discriminator to separate a rich client from a thin. We bind widgets to properties using data binding, and we use observable label providers in grids.
    • Set rather than List or Collection. Design rationale: to ensure proper data binding and stable collections, we need a distinct collection type. By definition (?) a relational DB returns unique instances in undefined order. All grids sort rows on user request, and a Set is easier to diff/merge in general. All in all, Sets fit the bill better than Lists, and hence all core signatures accept and return Sets unless there is a specific reason.
  • Menus, Actions and Commands
    • Menu items (both main and popup) are primarily declared thru extension points, not attached directly to viewers. This makes common commands universally available; whenever and wherever an Artist is selected, a menu with all applicable Artist commands is available.
    • Actions vs. Commands - Commands are "new school" and more powerful, Actions are "old school" and less powerful. However, the command framework is pretty abstract and - to most people - confusing. We should use Commands to define "global" actions that we bind to keyboard shortcuts, but we use regular Actions and Runnables where a Command isn't required.
  • Nebula - if we want to stay RAP-compatible, we can probably not use any Nebula components. In time, we may offer alternative implementations (RCP vs RAP). If we ignore RAP compliance, these Nebula components would be of particular interest:
    • Grid - the Nebula grid offers most of the features that the standard Eclipse Tables and Trees lack. All lists, trees and tables could be replaced by the grid.
    • PShelf - could replace ExpandBar as the primary navigation widget.
  • UI Style and "Skins"
    • Now (Eclipse 3.x): we run with the default appearance produced by the Forms Toolkit.
    • Then (Eclipse 4): we use the new (CSS-oriented) way of styling the application. It is too much work to do that using the current platform.
  • Target platform - a pre-configured RCP target platform is downloaded and provided by Maven. This includes the RCP base framework and all desired plug-ins to avoid the dependency on individual installations.
  • Plug-in Component structure - we separate the client in a few main parts. The basic idea is to have a small base product that is easily installed and rarely updated, and to use an update site to maintain the other components.
    • Installer - an almost empty "bootstrap" to allow installation/update of other components from update site
    • Product - splash screens, license, intro pages, etc
    • Foundation - fundamental UI components; custom widgets, utils, common abstractions, ...
    • Server Connection (Data Source) - abstracts the server facade and produces UI-friendly objects (lazily loaded, observable, named ...)
    • UI plugins:
      • Navigator UI - A PShelf presentation of "shallow" objects, with the ability to "inflate" any object and open an editor on it
      • Core model editors - EditorPart subclasses that operate on SMDEntity instances from the core model
      • Subjective model editors - EditorPart subclasses that operate on SMD instances from the subjective model
  • i18N
    • At the time of writing, the prototype is not localizable. We should of course change this at some point in time, using the built-in Eclipse/Java mechanisms to do so.
    • character set is UTF-8. All projects should have this setting defined, to avoid dependencies and failures due to bad workspace settings.

Developer Notes

A few notes that may or may not be useful for RCP developers.


  • Launcher doesn't launch
    • Q: Sometime the launcher just won't launch stuff from within the IDE, even though everything seems to be in order.
    • A: delete the launcher form the "Run Configurations" menu, and re-launch it by right-clicking the checked in launcher ("Run As - Eclipse Application")

External Links

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.