The definition of a rich client application plug-in starts out similarly to the other plug-ins we've been studying. The only difference in the first part of the markup is that the list of required plug-ins is much smaller than we've been used to!
<?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.0"?> <plugin id="org.eclipse.ui.examples.rcp.browser" name="%pluginName" version="3.0.0" provider-name="%providerName"> <runtime> <library name="browser.jar"> </library> </runtime> <requires> <import plugin="org.eclipse.core.runtime"/> <import plugin="org.eclipse.ui"/> </requires>
Up to now, we've contributed function to the platform workbench by declaring extensions that add elements to the workbench. In all of the plugin.xml content that we've reviewed so far, we've only looked at individual contributions to a workbench that is assumed to be there. On the rich client platform, there is no application already defined. Your rich client plug-in is the one responsible for specifying the class that should be executed when the platform is started. This is done in the org.eclipse.core.runtime.applications extension.
<extension point="org.eclipse.core.runtime.applications" id="app" name="%appName"> <application> <run class="org.eclipse.ui.examples.rcp.browser.BrowserApp"> </run> </application> </extension>
In this extension, we specify the class that should be run when the platform is first started. This class must implement IPlatformRunnable, which simply means that it must implement a run method. The run method is responsible for creating the SWT display and starting up a workbench. The class PlatformUI implements convenience methods for performing these tasks.
public Object run(Object args) throws Exception { Display display = PlatformUI.createDisplay(); try { int code = PlatformUI.createAndRunWorkbench(display, new BrowserAdvisor()); // exit the application with an appropriate return code return code == PlatformUI.RETURN_RESTART ? EXIT_RESTART : EXIT_OK; } finally { if (display != null) display.dispose(); } }
The call to createAndRunWorkbench will not return until the workbench is closed. The SWT event loop and other low-level logistics are handled inside this method. At this stage, it's not so important that you understand the underlying mechanics in running an SWT application. This code can be copied to your rich client application with minimal changes. In fact, the hook for you to add your own functionality is the WorkbenchAdvisor that is passed as an argument when the workbench is created. Let's take a closer look.