Community
Participate
Working Groups
RC1 When I install something from a p2 repository, the download process looks rather hectic as a dialog telling me that the "user operation is blocked" is opened and closed. I think this results from the work that recently happen in the p2 transport layer around the ability to cancel downloads.
Needs investigation.
Only effects the wizard. When run in the editor, the blocking progress dialog does not appear. Pascal, can you tell us what changed here in p2?
What we are doing on the PDE side, nothing unusual as far as I could find: 1) We get the wizard container and ask it to run an IRunnable getContainer().run(true, true, new IRunnableWithProgress) 2) The IRunnableWithProgress calls out to our model to resolve passing the progress monitor 3) The model calls out to p2 code (the planner) to create a provisioning plan passing it a subprogressmonitor.
The changes that I'm talking about are the one that happened in https://bugs.eclipse.org/bugs/show_bug.cgi?id=275975
Created attachment 136658 [details] Zipped sample plugin demonstrating the problem This simple plugin demonstrates the problem. Basically if a wizard operation tries to perform a job, you get this dialog. The UI should be suppressing this dialog (doing the same thing in a ProgressMonitorDialog doesn't open the second dialog).
This has nothing to do with PDE or p2.
Doing some research I found this was added in bug 58292. The rationale is that if a wizard operation is blocked by some background job, it needs to open this extra dialog because there is no way to reveal this information in the wizard dialog itself. This allows users to see what background jobs are running that are preventing the wizard from completing. It is interesting that ProgressMonitorDialog takes a different approach. It simply sets the blocked "reason" to be the progress message and pauses the progress indicator (see ProgressMonitorDialog.ProgressMonitor.setBlocked). Overall I think the ProgressMonitorDialog approach is a better user experience (no double dialogs). But it doesn't surface the information about the jobs that are blocking it. I think an in between approach would be to add a button or hyperlinked message when the dialog is blocked, and clicking this button/link would open the jobs dialog with further information. This would provide a smoother user experience, and also allow the underlying job information to surface.
Note this started appearing just recently in the PDE case because we previously weren't passing along the parent progress monitor all the way down into the transfer operation. This meant we were not responsive to cancelation at the lowest level. Hooking our progress monitors together allows the "blocked" state to propagate all the way up to the wizard dialog's progress monitor, which has the behaviour we see here. I believe it is unrelated to the cancelation job we added, which isn't running at the point where transfers are occurring (this job only runs during establishing a socket connection). It would be a bit of a hack, but the PDE wizard could avoid this by wrapping the wizard's monitor in a ProgressMonitorWrapper and overriding setBlocked/clearBlocked to just update the progress message rather than showing the dialog.
Filed bug 277347 against PDE. Using a wrapped progress monitor avoids the problem.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
