Exploring the Flexibility of Perspectives

As evidenced by over 67 pages of preferences and other configurable options, Eclipse is a very flexible platform; this flexibilty is matched in the user inteface through the use of perspectives. Perspectives define the set and layout of views and shortcuts in the workbench window. While developing a template for the perspectives extension I was able to explore the true power of perspectives. The easiest way to see their flexibility in action is by going through the "Customize Perspective..." pages in the Window menu. The majority of the UI's dynamic content can be modified using the three submenu selection windows on the Shortcuts tab and the numerous options on the Commands tab. An interesting exercise is to turn off all the standard options for a perspective and only add back the ones you intend to use; then save the perspective and use it for a while to see if you begin to use the shortcuts more now that you know where they came from.

When all the options are turned off through the custmization of the perspective, the views that remain are the contributions of the defining perspectives extension. The extension references a class file that is responsible for adding the various views, action sets, and shortcuts. The common method for adding views is to create an IFolderLayout with some position relative to the editor area and use the methods IFolderLayout.addView(String viewId) or IFolderLayout.addPlaceholder(String viewId) (adding a placeholder sets where the view will show up if it is enabled by the user at a later time). The best way of finding view ids is to look through the ui packages for the various platform components and find the id given in the views extension; additionally, the ids are sometimes given as API constants for the various packages. Then, calls to IPageLayout.addActionSet(String actionSetId) will provide the content for the menus and the toolbar and calls to IPageLayout.addNewWizardShortcut(String id) will provide the options shown when the user selects File > New. Again, the required ids can often be found as API constants or by looking at the id given in the respective extension of the various ui packages.Finally, calls to IPageLayout.addShowViewShortcut(String id) will populate the list of rapid navigation views in the Window> Show View submenu and calls to IPageLayout.addPerspectiveShortcut(String id) will generate the list of perspective options for the Window > Open Perspective submenu.

An example of this process can be seen in the class PDEPerspective where the steps are laid out quite logically and are easy to follow. I highly recommend playing with perspectives in order to experience just how much control is provided over the layout and presentation of the user interface.

For more information regarding perspectives, visit the online Help documentation.

Extension Point Templates: External Development

As a continuation from my previous entry regarding the development of templates for extensions points I will now explain how to create the template in a separate plug-in. The main steps are essentially the same; the two required extension points (org.eclipse.pde.ui.newExtensions and org.eclipse.pde.ui.templates) should be added with the appropriate elements, the template class file should be developed, and a templates_3.X folder should be created (where 3.X represents the package schema version) to hold the java and bin files.

The key change in the implementation is that the template class file should subclass OptionTemplateSection rather than PDETemplateSection (since PDETemplateSection is internal to the org.eclipse.pde.ui package). While the majority of the code can remain the same, the method getFormattedPackageName(String id) will need to be updated to so that the supplied package name corresponds to the usual naming standards. This involves replacing the call to super with functionality that will only use java identifier characters and a lower case letter to begin the package name. Furthermore, the abstract methods getInstallURL() and getPluginREsourceBundle() need to be implemented; some sample code is shown below:

protected ResourceBundle getPluginResourceBundle() {
Bundle bundle = Platform.getBundle(UITemplateMessages.Bundle_name);
return Platform.getResourceBundle(bundle);
}

protected URL getInstallURL() {
Bundle bundle = Platform.getBundle(UITemplateMessages.Bundle_name); return bundle.getEntry("/");
}

Note: The use of the variable UITemplateMessages.Bundle_name implies that there is an additional class file named UITemplateMessages that declares externalized strings and points to a file named messages.properties for their definitions.

Beyond making small adjustments to fit the specific extension point and confirming that all file references exist in the plug-in package, there isn’t much more that needs to be done. To test it, simply self host, find your template in the list of Extension Wizards and you’re on your way.