20.6. Modifying Eclipse to Find Part Identifiers

Defining new actions using the plug-in manifest editor is a straightforward process, except for finding those pesky identifiers for extending the context menus of specific views and editors (see Section 6.4, View Actions, on page 237 and Section 6.5, Editor Actions, on page 244). This information is not part of any plug-in manifest and thus must be obtained in some other manner.

One approach is to start with the registerContextMenu method in the org.eclipse.ui.internal.PartSite class and search for references, exploring the code and recording identifiers as you go. This is a viable but time-consuming approach that tends to become out of date as new versions of Eclipse arrive.

An alternate approach is a development utility that interrogates the active workbench part, be it an editor or a view, and dumps information about that part, such as the context menu identifiers, to the console. Unfortunately, the API for obtaining this information does not exist (see Section 20.2, Accessing Internal Code, on page 711), so before creating an action delegate, you need to modify the underlying Eclipse system to provide the appropriate accessor methods.

20.6.1. Modifying the Eclipse base

To modify the Eclipse base, you first need to check out the appropriate project from the Eclipse repository so that later you can create and submit a CVS patch. Submitting a CVS patch is how such changes are fed back to the Eclipse committers with the hope of getting integrated into the development stream. Connect to the Eclipse.org development repository by opening the CVS Repositories view (see Section 1.8.1, Getting started with CVS, on page 49) and selecting New > Repository Location. In the Add CVS Repository dialog, enter the following values.

Host "dev.eclipse.org"

Repository Path "/home/eclipse"

User "anonymous"

Password Leave this blank.

Connection Type "pserver"

Once connected, expand the HEAD tree element, locate the org.eclipse.ui.workbench project, and check it out in the workspace (see Section 1.8.2, Checking out a project from CVS, on page 50). Once it is checked out in the workspace, there may be some compile errors in the Problems view because the Eclipse being used may be different from the Eclipse against which the plug-in project was compiled. The plug-in project is compiled against the HEAD versions of other plug-in projects, but since it cannot locate those other plug-in projects in your workspace, it compiles them against the plug-ins in the current Eclipse installation. The following are several different ways to remedy this situation.

• Check out each Eclipse plug-in project on which this plug-in project directly or indirectly depends.

• Download and install (but do not launch) the latest Eclipse integration build, then retarget your current Eclipse environment to compile against plug-ins in the integration build using the Plug-in Development > Target Platform preference page (see Section 19.2.5, Editing with different versions of Eclipse, on page 692). The disadvantage is that all other plug-in projects in your workspace will also be compiled against this target platform.

• Check out a prior version of the plug-in project that compiles against the plug-ins contained in your Eclipse installation. The disadvantage is that if any of the code you write depends on functionality that has changed between the version you checked out and the HEAD, then it may not compile when you submit it back to Eclipse.org.

• Do as much as you can using one of the preceding approaches, then wait until the next Eclipse milestone build is released (they are usually very stable, whereas various integration builds are not). Download, install, and code against the new build and submit your changes as soon as possible back to Eclipse.org.

When the org.eclipse.ui.workbench project is loaded and its compile errors cleaned up, add the following methods.

org.eclipse.ui.internal.PopupMenuExtender

public String getMenuId() {
   return menuID;
}

org.eclipse.ui.internal.PartSite

public String[] getContextMenuIds() {
   if (menuExtenders == null)
      return new String[0];
   String[] menuIds = new String[menuExtenders.size()];
   int index = 0;
   Iterator iter = menuExtenders.iterator();
   PopupMenuExtender extender;
   while (iter.hasNext()) {
      extender = (PopupMenuExtender) iter.next();
      menuIds[index] = extender.getMenuId();
      index++;
   }
   return menuIds;
}

20.6.2. Creating the global action

Next, you will create an action delegate capable of using this newly introduced API. In the plug-in project of your choice (e.g., the Favorites plug-in project, but not the org.eclipse.ui.workbench plug-in project), define a new workbench menu and menu item in the plug-in manifest (see Section 6.2, Workbench Window Actions, on page 209), give it a name similar to "Show Part Info," and associate it with the action delegate that follows. Be sure to modify that plug-in's classpath to reference the org.eclipse.ui.workbench project in the workspace rather than the org.eclipse.ui.workbench external plug-in, and make sure that org.eclipse.ui.workbench is in the required plug-ins list in the plug-in manifest.

package com.qualityeclipse.favorites.actions;

import ...

public class ShowPartInfoActionDelegate
   implements IWorkbenchWindowActionDelegate
{
   public void init(IWorkbenchWindow window) {
      // ignored
    }

   public void selectionChanged(IAction action, ISelection selection)
    {
      // Ignored.
    }
   public void run(IAction action) {

      // Determine the active part.
      IWorkbenchPage activePage =
         PlatformUI
            .getWorkbench()
            .getActiveWorkbenchWindow()
            .getActivePage();

      IWorkbenchPart activePart =
         activePage.getActivePart();

      // Search editor references.
      IEditorReference[] editorRefs =
         activePage.getEditorReferences();

      for (int i = 0; i < editorRefs.length; i++) {
         IEditorReference eachRef = editorRefs[i];
         if (eachRef.getEditor(false) == activePart) {
            printEditorInfo(
               eachRef,
               (IEditorPart) activePart);
         }
      }

      // Search view references.
      IViewReference[] viewRefs =
         activePage.getViewReferences();

      for (int i = 0; i < viewRefs.length; i++) {
         IViewReference eachRef = viewRefs[i];
         if (eachRef.getView(false) == activePart) {
            printViewInfo(eachRef, (IViewPart) activePart);
         }
      }
   }

   private void printEditorInfo(
      IEditorReference editorRef,
      IEditorPart editor) {

      printPartInfo(editorRef, editor);
   }

   private void printViewInfo(
      IViewReference viewRef,
      IViewPart view) {

      printPartInfo(viewRef, view);
   }
   private void printPartInfo(
      IWorkbenchPartReference partRef,
      IWorkbenchPart part) {

      println(partRef.getTitle());
      println("  id = " + partRef.getId());
      IWorkbenchPartSite site = part.getSite();
      if (site instanceof PartSite) {
         String[] menuIds =
            ((PartSite) site).getContextMenuIds();
         if (menuIds != null) {
            for (int i = 0; i < menuIds.length; i++)
               println("  menuId = " + menuIds[i]);
         }
      }
   }

   public void println(String line) {
      System.out.println(line);
   }

   public void dispose() {
      // Ignored.
   }
}

20.6.3. Testing the new utility

Create a new launch configuration (see Section 2.6, Debugging the Product, on page 88) and launch a Runtime Workbench to test the new utility. Be sure to modify the launch configuration so that it references the org.eclipse.ui.workbench project in the workspace rather than the org.eclipse.ui.workbench external plug-in. When you activate an editor or view and then select the new global action from the workbench menu bar, you will see the workbench part's information appear in the Console view of the Development Workbench.

20.6.4. Submitting the change to Eclipse

After you've created a useful addition to Eclipse and decided that it's of no real commercial value yet it might really help other developers, you can post it to a Web site for others to download and use as they choose; or better still, you can submit it to Eclipse.org for inclusion in the Eclipse base via Bugzilla (see Section 20.2.2, BugzillaEclipse-bug tracking system, on page 712).

For example, if you were to submit the modifications made to the Eclipse base (see Section 20.6.1, Modifying the Eclipse base, on page 727), you would follow these steps: