Community
Participate
Working Groups
Client code that makes use of InstallAction has no way of providing users with feedback that something is happening before the wizard is displayed. ProfileModificationAction schedules a background job to do some processing and network activity. There should be a way to provide ProfileModificationAction with an IRunnableContext in which the job is run.
Created attachment 136607 [details] mylyn/context/zip
I don't think we will ever modify InstallAction to perform resolution in a runnable context. Resolution requires network access and should be non-blocking. It will likely always be performed in a background job rather than providing API to control this. I think the real problem is that when the user has "always run in background" set to true, the progress monitor is not shown. Otherwise it will be. See bug 269958, in particular bug 269958 comment 8.
Please consider this use case: Mylyn is providing a 'connector discovery' wizard to enable easier discovery of installable Mylyn connectors. The wizard gives the user a means of selecting installable features. When the user presses 'Finish' on the wizard Mylyn passes the selected features to InstallAction. From the user's perspective the wizard finishes and disappears, and nothing happens. This results in very poor usability since it's very confusing to the user. They expect something to happen, and since they're in a wizard they expect it to be blocking.
David, try to get in touch with the WTP guys as they have just rebased their server adapter wizard on p2. There may be a good opportunity for sharing.
We have the same problem throughout the SDK (bug 269958 comment 8). I'm not saying I like the problem, just saying that I don't plan to fix it specifically in p2. If the user has "always run in background = true" then the progress monitor is hidden. I think you/we should push on that bug, the current suggestion is to flash the progress monitor. The ProfileModificationAction hierarchy is specifically setup for our workflows where we resolve in the background. This is by design, as resolution can be quite expensive and we allow the user to keep working while this happens. I don't see changing this, and in fact I'm not sure how these actions will manifest in API, we would probably expose them as handlers. There will be change in this area before it becomes API. If what you want is to resolve the install in the context of your wizard container's progress bar and then immediately open the install wizard, then you can create your own profile change request using the static method in InstallAction and then run the PlannerResolutionOperation using the monitor of your wizard. At that point, you can open up the PreselectedIusInstallWizard with the resolved operation. Should be straightforward. If it's not, then that is what I think we should focus on. Maybe there's some kind of feature request implied by your specific install action request, but I don't think InstallAction is the way to handle this.
(In reply to comment #5) > If what you want is to resolve the install in the context of your wizard > container's progress bar and then immediately open the install wizard, then you > can create your own profile change request using the static method in > InstallAction and then run the PlannerResolutionOperation using the monitor of > your wizard. At that point, you can open up the PreselectedIusInstallWizard > with the resolved operation. Excellent, that's exactly what I was looking for... thanks for spending the time to explain it.
