Building a Great GUI using Eclipse RCP Choices and Consequences

1. Building a Great GUI using Eclipse RCPChoices and Consequences Boris Bokowski Kevin McGuire IBM Ottawa Lab

2. 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)

3. 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

4. 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)

5. Eclipse Platform Architecture Other Tools (CDT etc.) PDE JDT Rich Client Application IDE Text Compare Team/ CVS Debug Search Help (Optional) Update (Optional) Text (Optional) IDE Workspace (Optional) Generic Workbench (UI) Rich Client Platform JFace SWT Platform Runtime (OSGi) Java VM

6. Workbench: Views, Editors, Perspectives Menu Perspective Switcher Toolbar View Editor Trim (Status, Progress, …)

7. Wizards, Dialogs, Preferences, Progress Export Wizard Preferences Dialog Progress View Progress Area

8. UI Forms – Flat look

9. Welcome, Help, Cheat Sheets Welcome Page Cheat Sheet Help Browser

10. 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

11. Typical Solution “Shapes” • There are various canonical rich client app “shapes” that result from including the various Eclipse technologies: • The SWT App • The Information Navigator • The Extensible Platform • The Extensible IDE

12. 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

13. Examples: Sudoku, Azureus

14. 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

15. 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 Example: Sametime

16. 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 • Usually does not include • Hooks for contributing views, menus, etc.

17. Tabular data with structure (think Spreadsheet with links between rows) Graphical editor 29 meg total,2.3 meg authored Example: METUS

18. 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) • What you’ve bought into: • 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

19. Tech: Selection Service • Why you want it: • Every view/editor can provide selection, or respond to selection • What you’ve bought into: • 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!

20. 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 • Usually does not include • Resources

21. 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 • What you’ve bought into: • Complexity of open systems • Overflowing menus, preferences, etc. • Loss of control

22. 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

23. 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)

24. Examples: Gumtree, Adobe Flex Builder 2

25. 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 • What you’ve bought into: • Editor stacks and view stacks are separate, take up different real estate, can’t be combined • Editors are shared across perspectives

26. RCP Specific Advantages

27. 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

28. Branding

29. 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.

30. 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

31. 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 • Addison-Wesley Professional • ISBN: 0321268385 • Contributing to Eclipse: Principles, Patterns, and Plugins • By Erich Gamma, Kent Beck • Addison-Wesley Professional • ISBN: 0321205758

32. Advanced Topics

33. 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)

34. 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) • What you’ve bought into: • 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)

35. 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

36. 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

37. Tech: Common Navigator • Framework for defining navigator-like views • Extensible – other plug-ins can contribute content • In the IDE as “Project Explorer”

38. 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 • What you’ve bought into: • More framework to understand

39. 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 • What you’ve bought into: • 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

40. 20 meg total, 4.3 meg authored Example: Eclipse Trader

41. 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