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.