Q1

Action are the old way of attaching executable content to menu items. A command is an abstract representation of the effect, which does not need to have a UI component. Action should not be used as they have been depreciated for some time and may be removed from a future version of the platform.

Q2

A command can be associated with a handler to provide a menu item. Handlers are indirection mechanisms that allow the same menu (for example, copy) to take on different commands based on which context they are in. It is also possible to have a default command ID associated with a menu to avoid this indirection.

Q3

The M1 key is an alias for Cmd on OS X, and for Ctrl on other platforms. When defining standard commands such as copy (M1 + C) it has the expected behavior on both platforms (Cmd + C for OS X and Ctrl + C for others).

Q4

Keystrokes are bound to commands via a binding, which lists the key(s) necessary to invoke and the associated command/handler.

Q5

A menu's locationURI is where it will contribute the entry to the UI. These are specified either as relative to an existing menu's contribution, or to its generic additions entry. It is also possible to specify custom ones, which are associated with custom code.

Q6

A pop-up menu is created by using the special locationURI popup:org.eclipse.ui.popup.any. Note that the objectContribution is not as flexible and may be removed from the platform in future.

Q1

The syncExec() method will block and wait for the job to complete before continuing the code. The asyncExec() method will continue to run after posting the job but before it completes.

Q2

The Display class runs jobs on the SWT UI thread, but the UISynchronize instance can be used to run jobs on non-SWT UI threads as well. For E4 applications, the UISynchronize is preferred.

Q3

The UIJob will always run on the UI thread of the runtime, and direct access of widgets will not run into a thread error. Care should be taken to minimize the amount of time spent in the UI thread so as not to block Eclipse. The job will run on a non-UI thread, and so it does not have access to acquire or modify UI threaded objects.

Q4

The Status.OK_STATUS singleton is used to indicate success in general. Although it is possible to instantiate a Status object with an OK code, doing so only increases the garbage collection as the Status result is typically discarded after execution.

Q5

The CommandService can be obtained via the general PlatformUI.getWorkbench().getService() call, which takes a class and returns an instance of that class. The same technique can be used to acquire a UISynchronize instance.

Q6

An icon can be displayed by setting a property on the job with the name IProgressConstants2.ICON_NAME.

Q7

SubMonitor are generally easier to use at the start of a method, to ensure that the monitor being passed in is correctly partitioned as appropriate for the task in hand. The SubProgressMonitor should generally not be used.

Q8

The cancellation should be checked as frequently as possible so that as soon as the user chooses to cancel the Job, the Job is aborted.

Q1

An informational dialog is shown with MessageDialog.openInformation() (and also .openWarning() and .openError() as well). There is also a MessageDialog.openConfirmation() call, which returns the value of a yes/no answer to the user.

Q2

The StatusManager is an Eclipse 3.x class, which is tightly coupled to the UI. The StatusReporter provides the same basic intent, but without a UI association.

Q3

The status reporting is asynchronous by default; although a BLOCK option exists to make it synchronous.

Q4

To combine the results of many things into one report, use a MultiStatus object.