Community
Participate
Working Groups
The CVS password prompter is often launched from a background job. Thus, it is hard to determine the proper parent to use for the dialog shell. We cannot use the view from which the background job was launched because it may be closed by the time the prompt occurs, or worse, it could already be parenting a modal shell (thus causing deadlock). This is complicated enough that the Workbench should provide some mechanism for determing the proper parent to use. To that end, the CVS prompter currently passes a null shell to the dialog constructor and relies on the Workbench's parent determination mechanism. This will determine a parent in such a way that deadlock does not occur but does not provide the best parent (see bug 99472 for more details). If the best parent can be determine (or at least a better parent than none) than it probably should be used. If the general concensus is that this mechanism was not intended for the purpose that CVS is using it than it would be benefitial for the workbench to address this issue separately (i.e. openeing dialogs from a background job).
You should use a ShellProvider. The default behaviour will choose one for you if you don't have a good choice. You have more context than use so I am not sure how we could choose a better parent than you.
There are two issues here: 1. The workbench should protect against opening modal dialogs in a manner that deadlocks the app. On this issue, I agree. We should have universal protection here. The current implementation includes this code in defaultModalParent: // Make sure we don't pick a parent that has a modal child (this can lock the app) if (parent == null) { // If this is a top-level window, then there must not be any open modal windows. parent = getModalChild(Display.getCurrent().getShells()); } else { // If we picked a parent with a modal child, use the modal child instead Shell modalChild = getModalChild(parent.getShells()); if (modalChild != null) { parent = modalChild; } } We should move this to getParentShell so that runs for all modal dialogs (not just ones with null parents), making it impossible to create a deadlock by selecting a bad parent. 2. Provide a framework for background jobs to interact with the user, that permits the output of the job to be displayed in multiple locations at once. IMHO, this is only a problem if there are multiple places to display output. If the user has closed all views that are affected by the background job, then they no longer care about the job and should not see ANY output from it - so there is no problem. I believe that issue 2 is a separate, and less general, issue.
org\eclipse\ui\internal\performance
Tod, what does your last comment mean (or did you mean that for another bug)?
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
