Difference between revisions of "E4/EAS/Progress Service"

Revision as of 13:40, 29 October 2009

Based on a user's interaction with an application, the application may wish to schedule work to be done by other worker threads. The work that is done on these other worker threads may or may not be presented to the user. If background work is being invoked automatically based on some conditions, it may not necessarily be useful to present this information to the user. However, if the user explicitly invokes an action that causes a long-running operation to begin, they may wish to know about this so that they can respond accordingly when the operation has completed or just cancel the operation outright.

Eclipse 3.x API

In Eclipse 3.x, there are a variety of classes and interfaces that exposes progress reporting and work scheduling features.

• org.eclipse.jface.operation.IRunnableContext
• org.eclipse.ui.progress.IProgressService
• org.eclipse.ui.progress.IWorkbenchSiteProgressService
• org.eclipse.jface.operation.IRunnableWithProgress
• org.eclipse.core.runtime.jobs.Job

Typically, for scheduling work to be completed by a worker thread, the Jobs framework is used.

Job aJob = new Job("My long-running operation...") {
  protected IStatus run(IProgressMonitor monitor) {
    // do stuff and report progress via the IPM
    return Status.OK_STATUS;
  }
};
// true to indicate that this job was initiated by a UI end user
aJob.setUser(true);

In the IProgressService and IWorkbenchSiteProgressService case, these are queried from the local service locator.

Critique:

• We need a headless IRunnableWithProgress (today we have JFace IRunnableWithProgress, Job.run(IProgressMonitor), equinox futures IProgressRunnable.) If we had a core-level IRunnableWithProgress then applications could define runnables that could be run in different execution contexts (UI modal context, user job, future, etc.) Today the application has to define its own operations framework to handle these differences.
• Likewise, we need a headless progress service (generalization of IWorkbenchSiteProgressService) so that jobs/runnables can be run in these different execution contexts with different style progress reporting depending on where they are run. See Bug 293098.
• Examples of 3.x limitations
  • If you a run a job in a modal dialog, there is no jobs progress dialog and your only progress indicator is the status bar unless you happen to have the progress view open.
  • Some constructs (DeferredTreeContentManager) use jobs and only know about certain progress contexts. If I run a deferred fetch in a site, the site is adorned and the job progress is reported normally. If I run the same viewer in a dialog, there is no local progress.

e4 (Java)

Need to review the AC's meeting minutes prior to the creation of this e4 API.