Bugzilla – Full Text Bug Listing
| Summary: | [ui] Size dialog seems to create a new plan | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jfrantzius, susan |
| Version: | 3.4 | ||
| Target Milestone: | 3.4 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
Each IU is sized individually, so an individual plan is created for each. We've discussed in the past that these sizes may not be completely accurate anyway, but said we'd keep it this way for now. Given that the creation of a plan is not a cheap operation I suggest that we size the plan we get back and provide one dl size for the whole set of things. Also I don't think we should allow for deselection of IUs to install as the plan will need to be recomputed. I agree that if the size computation takes too long it's of little value to the user anyway, because lately I just skip over the computation and move through the wizard. We can put the size info in the details area. I disagree that recomputing the plan on selection is bad. It is our way to let the user experiment with trying to fix a bad plan. The other alternative is to force them to leave the dialog, go back to the available features dialog, select again, and then recompute the plan anyway. There is progress shown in the dialog as the plan recomputes, and this is also what update manager users are used to being able to do. *** Bug 226114 has been marked as a duplicate of this bug. *** (In reply to comment #4) > *** Bug 226114 has been marked as a duplicate of this bug. *** > I was seeing the stack traces in bug#226114 after I finished the install dialog, while already seeing the install progress bar in the Progress View. I wonder why any size computation should take place once I have decided to install? It is a bug. This is because we do not stop the job doing the size computation. If you feel like hacking some p2 code you are welcome to take a stab at this one. fixed in HEAD >20080408. What we do now in the install/update/uninstall dialogs is size the initial plan passed to the dialog. The sizing still occurs in a background job so as not to hold up the UI. Now there will be one background job running when the dialog opens, rather than N (one per IU). If the plan is recomputed due to checking or unchecking/ius in the wizard, then the sizing computation job is scheduled again (still in the background, not in the resolution runnable happening in the UI). The old code whereby the elements compute individual sizes remains, and I have simply used a variable in the element class to determine whether individual sizes are computed and shown. This allows us to keep the code for now, in case we decide to go back to this mechanism, or to make it a user preference. I also made some changes to the old code to deal with the issue of stopping the size computations when no longer needed. The old code did not pass a progress monitor to the engine in the sizing phase. So even if the sizing jobs were cancelled, there was no way for the engine to know about this and decide to stop its computations. The sizing protocol now passes around the job's progress monitor so that cancellation is possible. Note that it's up to the engine to actually check the monitor, and if it doesn't, these sizing jobs would keep running until returning to the UI. Same is true for the new "one total size" job. The job is cancelled in the UI when the user leaves the dialog, but if the size computation is already being performed in the engine and the engine doesn't check the cancel status of the monitor, it will still do the work. (In reply to comment #7) > fixed in HEAD >20080408. I tried it with N20080408-2000, installation now is lightning fast, and a breeze in general :) P2 rocks! |