Community
Participate
Working Groups
The public RCP-API does not support any progress displaying for asynchronous jobs if somebody decides to create his own window content by overriding WorkbenchAdvisor's createWindowContents method. It seems that there is a strong need for decoupling at least the classes "ProgressRegion", "WorkbenchWindow", "ProgressMonitorFocusJob" (strong dependency through the call to "ProgressManagerUtil.animateDown") and "ErrorNotificationDialog" (strong dependency through the call to both "ProgressManagerUtil.animateDown" and "ProgressManagerUtil.animateUp").
Tod, can you comment? Is there any existing API to allow someone to roll their own equivalent of the progress indicator and/or jobs view, essentially replacing the workbench's current hardwired policy for showing progress?
*** Bug 77820 has been marked as a duplicate of this bug. ***
Comment from bug 77820: Configuring the workbench with "setShowProgressIndicator(false)" and at the same time letting the workbench create its default window contents, leads to the same effect. Hence, not only the progress indication on the status line is turned off but also there are no dialogs from ProgressMonitorFocusJob showing up anymore.
Yes - you can set the IProgressProvider of the JobManager to be you own. Having said that it is a lot of work to do a good one so making ours more pluggable is likely a worthwhile effort. However this is a big job and would have to be a plan item for us to find time to do it.
Nick I noticed you also marked this for 3.1. What is it you expect?
For 3.1, I would like us to consider opening up policies like this for RCP apps to replace, if the default policy is not appropriate for their app. For the progress monitoring, I think it's important to make this possible. Making it easy would be nice too, but not essential for 3.1.
Its currently possible, and arguably not that difficult. To do it correctly there are some internal UI classes that have to be accessed, but that is all. This may not be a high priority since there is pluggability via the IJobManager.setProgressProvider() method.
Beat, can you comment on whether using Platform.getJobManager().addJobListener(...) would work for you?
It is not that the default policy is not suitable for us. It is the opposite: We want to use it because it makes a lot of sense and saves a lot of time (see #4). (We absolutely do not want to start with coding our own progress provider.) The thing is that we are in a situation where we have to create our own window contents (overriding the WorkbenchAdvisor's "createWindowContents"-method). This, at the moment, disables all that usefull job progress displaying support given to us from the RCP. A simple check in both "ProgressManagerUtil.animateUp()" and "ProgressManagerUtil.animateDown()" to check whether the ProgressRegion is null would be an important part of the remedy. (This was also suggested in bug #76830 and would make sense anyway.) This is because then the ProgressRegion could be managed outside the internal workbench window, making it possible to fully use the default job progress displaying - with the exception that the zooming effect caused by these two methods would be lost. (Of course, instantiating the internal ProgressRegion outside of the internal workbench still remains unsatisfactory.) [Another small thing is that configuring the workbench with "setShowProgressIndicator(false)" leaves the ProgressRegion in the WorkbenchWindow uninitialized. Setting it to null would clarify the situation.]
See also bug 74907. This covers the more advanced customization described by Jean-Michel and I above. As Beat requests here, RCP apps should be able to reuse the existing progress indicator in their own custom window layouts. Something along the lines of IWorkbenchWindowConfigurer.createProgressIndicator(Composite parent) should suffice. See also the more general bug 73821. Keeping this one open specifically for the progress indicator.
Should really have more general API than continuing to add createXYZ methods on IWorkbenchWindowConfigurer. E.g. make ProgressRegion more self-contained and promote it to API.
Have to defer this to post-3.1.
Reassigning bugs in component areas that are changing ownership.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
