building a great gui using eclipse rcp choices and consequences

© 2002 IBM Corporation

Confidential | Date | Other Information, if necessaryApril 19, 2023

Building a Great GUI using Eclipse RCPChoices and Consequences

Boris Bokowski

Kevin McGuireIBM Ottawa Lab

Copyright © 2006 IBM Canada, Inc., Made available under the Eclipse Public License v 1.0

Agenda

Rich Client Applications vs. Rich Client Platform

UI building blocks

Major UI decisions for RCP apps

How this results in typical patterns, examples

Advantages specific to building RCP apps

(Not about UI design in general, or how to layout widgets)


Eclipse Rich Client Application

Client application with rich user experience

Eclipse technology enables picking and choosing of components

Select those UI features which are appropriate for your problem domain and user


Eclipse Rich Client Platform

Standard packaging of plug-ins, platform for rich client apps

Component model, extensible

9.7 MB as of Eclipse 3.2.1

Smaller footprint is achievable (you lose extensibility)

Copyright © 2005 Dr. Frank Gerhardt, Made available under the Eclipse Public License v 1.0

Eclipse Platform Architecture

Platform Runtime (OSGi)SWT

JFace

Workspace(Optional)

Generic Workbench (UI)

Update(Optional)

Text(Optional)

IDEText Compare Debug Search

Team/CVS

IDE

Ric

h C

lien

t P

latf

orm

JDTPDEOther Tools(CDT etc.)

Rich ClientApplication

Help(Optional)

Java VM


Workbench: Views, Editors, Perspectives

Perspective Switcher

EditorView

Toolbar

Trim (Status, Progress, …)

Menu


Wizards, Dialogs, Preferences, Progress

Preferences DialogExport Wizard

Progress View Progress Area


UI Forms – Flat look


Welcome, Help, Cheat Sheets

Welcome Page

Cheat Sheet

Help Browser


Why RCP?

Quickly build a professional-looking application, with native look-and-feel, on multiple platforms

Components that form RCP are of high quality, are actively maintained, and are open source

Many other Eclipse components are available for reuse (e.g. Help UI, Update Manager, Cheat Sheets, Intro, etc.)

Inherent extensibility of Eclipse allows you to build an open-ended platform

Focus on the value-add of your application


Typical Solution “Shapes”

There are various canonical rich client app “shapes” that result from including the various Eclipse technologies:

1. The SWT App

2. The Information Navigator

3. The Extensible Platform

4. The Extensible IDE


Type 1: The SWT App

Best for:

Lightweight applications with little navigation and no need for extensibility

Usually includes:

SWT, JFace (Wizards, Dialogs, Preferences)

Sometimes includes:

OSGi, Help, Update, Forms

Usually does not include

Workbench

Views and Editors, including standard views such as Navigator, Outline


Examples: Sudoku, Azureus


Tech: Custom layout (SWT/JFace without Workbench)

Why you want it:

If don’t need to reuse existing views/editors

And your app doesn’t require view/editors

Full control over visual layout/presentation

You can still use Wizards, Dialogs, Jobs, Help, Update

What you’ve bought into:

Lack of extensibility

You get less for free and must write more code for real estate management


Example: Sametime

Does not look like Eclipse at all

Based on

OSGi, SWT, JFace, Forms, Update, Help

Plug-in extensions e.g. for link detection

What is different

Menu structure (e.g. Preferences)

Branding (colours, icons, etc)

Layout

What IS like Eclipse

Preferences Page

Help


Type 2: The Information Navigator

Best for:

Information intensive applications with some degree of focus

Management of remote information/services

Usually includes:

(All from Type 1)

Workbench, Views, OSGi plug-in support

Sometimes includes:

Perspectives, Editors, Help, Update, Forms


Hooks for contributing views, menus, etc.


Example: METUS

Tabular data with structure (think Spreadsheet with links between rows)

Graphical editor

29 meg total,2.3 meg authored


Tech: Workbench

Why you want it:

Real estate management (docking, moving, closing, min/max, etc)

Enables an extensible UI where other plug-ins contribute views

Option: Perspectives (if your app has different modes)


User can rearrange views and editors (loss of control)

It is easier to write your views if you know the real estate allocated for them

Tabbed look and workflow

Minimize/maximize can be confusing for new users


Tech: Selection Service

Why you want it:

Every view/editor can provide selection, or respond to selection


Since selection service is global, all views must be prepared for selection of unrelated types

No privileged relationships between certain editors / views

Switching between views may change the selection

Wayne says,

Tight integration with loose coupling is good!


Type 3: The Extensible Platform

Best for:

“Workbench” type information apps encouraging 3rd party plug-ins

Usually includes:

(All from Type 1&2)

Editors, Help, Update, Welcome

Sometimes includes:

Forms, Cheat Sheets

Standard views such as Navigator, Outline, Properties


Resources


Tech: Making your UI Extensible

Why you want it:

Let plug-ins contribute views, editors, perspectives, menu items, preference pages, wizards, …

Be an open platform

As an RCP app, you define where the UI is extensible and where it isn’t


Complexity of open systems

Overflowing menus, preferences, etc.

Loss of control


Example: UDig

Spatial data viewer/editor

Emphasis on the OpenGIS standards for internet GIS, the Web Map Server and Web Feature Server standards

Common Java platform for building spatial applications with open source components


Type 4: The Extensible IDE

Best for:

Rich development environments with many views, editors

Data models with complex dependencies that must be maintained

Usually includes:

The whole enchilada!

Including resources (workspace)


Examples: Gumtree, Adobe Flex Builder 2


Tech: Editor vs. View

Why you want it:

Your workflow requires an explicit open/modify/save/discard/revert lifecycle (long edit cycles)

You get to use our actions for Save/Save All/Save on Close (unsaved changes prompt)

Can be textual or diagrammatic


Editor stacks and view stacks are separate, take up different real estate, can’t be combined

Editors are shared across perspectives


RCP Specific Advantages


RCP is “On Top”

With SDK plug-ins, there is no concrete notion of “product” since 3rd party plug-ins can be added by consumer/repackager

But in RCP apps, everything that happens is under your control as the RCP app writer

RCP allows you to precisely control UI interaction:

Can carefully orchestra task flow

Can prevent contributions to UI (menus, views, etc)

Can provide limited extensions in a controlled manner

Can specialize through branding configuration

You can know exactly what the user is looking at

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0

Branding


Summary

RCP gives you an incredible amount of building blocks so you can focus on the value that your application adds

There is no one “look” to RCP applications, their style is varied according to the problem domain and audience

RCP gives you a lot of flexibility in how you assemble an application

RCP apps can be as simple as a game…

Or you can build advanced RCP apps that support third party plug-in contribution

You can add/remove to further customize, reduce footprint, etc.


Technology Choices

When you pick from the list of technologies to use, you enable new features or ways or working/presenting in Eclipse

However, you also buy into certain workflows or interactions

You need to be aware of these implications

Copyright © 2006 Eclipse Foundation, Inc., Made available under the Eclipse Public License v 1.0

Recommended Reading

Eclipse Rich Client Platform By Jeff McAffer and Jean-Michel Lemieux

Addison-Wesley Professional

ISBN: 0321334612

Official Eclipse 3.0 FAQs by John Arthorne, Chris Laffra


ISBN: 0321268385

Contributing to Eclipse: Principles, Patterns, and Plugins

By Erich Gamma, Kent Beck


ISBN: 0321205758


Advanced Topics


Other Technology (Eclipse Projects)

Nebula – Supplemental Custom Widgets for SWT

Graphical Editor Framework (GEF)

Graphical framework (boxes, lines, attachments) 1.2 meg

Eclipse Modeling Framework (EMF)

Property change events Default serialization/deserialization 1.3 meg

BIRT

Data Tools Platform (DTP)

Eclipse Communication Framework (ECF)

Embedded Rich Client Platform (eRCP)


Tech: Perspective

Why you want it:

Where distinct tasks groupings require different information (e.g. develop/debug)

Good for mode changes (e.g. Outlook calendar vs. mail)


Editors are shared between perspectives

User can modify perspective, add their own, change the look of your application (maybe detracting from branding)

You can no longer be sure for a given task the set of views the user has before them

(Using a fixed perspective, or non-closable / non-moveable views, you can maintain a certain level of control)


Tech: How to make it not look like Eclipse

Use your own icons

Themes (colors and fonts)

Custom presentation

SWT custom controls

Owner draw in tables and trees


Tech: Information management workflow

Typical patterns of information management once you have views, or views and editors

Information source : usually some form of navigator

Content access : a view or editor to see/modify the contents of an object (e.g. text editor, diagram, video feed, form, etc)

Detail management : e.g. outline view, in place expansion of details in navigator, properties view

Search


Tech: Common Navigator

Framework for defining navigator-like views

Extensible – other plug-ins can contribute content

In the IDE as “Project Explorer”


Tech: Page Book View

Why you want it:

Certain views are tightly coupled with editor, enhance editing capabilities, e.g. Outline, Properties, Palette

Don’t want to end up with a Java outline view, C++ outline view (proliferation of views)

Solution: “Page Book View” has abstract function but not concrete implementation, editors contribute current page

Reuse benefits development but also user since simplifies user learning


More framework to understand


Tech: Workspace

Why you want it:

Deltas, Builders

Otherwise must generate “by hand” Very powerful if source resources have complex dependencies

CVS support for sharing

Tasks, markers

Local History


Larger footprint

Users can turn builders off

“Hard wired” task flow of resource modification triggering builds

This may be too indirect or magical for some users


Example: Eclipse Trader

20 meg total, 4.3 meg authored


Example: Maestro & Ensemble

NASA Mars rover planning tool

Tells the rover where to go, how many pictures to take

Now working on Ensemble Framework for NASA tool integration

building a great gui using eclipse rcp choices and consequences

Documents