Community
Participate
Working Groups
My entire machine seemed to freeze for a second while the "updates available" dialogue was appearing.
There is definitely a "dead spot" when any of the update or install dialogs are opening. There is no progress indicator and no hourglass. I will look into this after M3, I think I'm doing some resolving without a progress monitor before bringing the dialog up.
The "dead spot" between "resolving" and the opening of the dialog is when we are computing the size for each IU. I can modify this code so that this occurs in a progress indicator. We could also consider computing the total size rather than each available size, since total size really means more. Then, if the user unchecked any of the items, we could recompute the total. So I can definitely improve this by changing the way/frequency I get the size, but we may also want to look at whether there are any obvious corrections we can make in the engine to make this faster. I'll ping Simon again after I make some UI modifications.
Susan, while debugging some other problems, I recall having the impression that the planner was being called to compute the sizes. Is it the case?
For each IU needing update, I get a plan and pass that to the engine with a Sizing phase. This way, I show a size for each IU. The user can check which ones they want to update. Then, I get a plan for the group as a whole and have the engine actually perform it. So I am definitely exacerbating the problem by getting plans multiple times. If I were to size them as a whole, and if the user doesn't change the selections, I could get one plan and perform it. I could also optimize the single IU case. Having gotten a plan for sizing, there's no need to get it again. So I can optimize some things on my end and I think I should do that first.
Bug #210585 addresses responsiveness/progress/hourglass so that there is no UI blockage. It "seems" to perform better simply by making the UI more responsive and giving feedback. Leaving this bug open to investigate whether computing the sizes as a unit will be significant improvement. I don't really want to tackle this unless/until I am doing some rework of the presentation of the install and update dialogs, so I'm not guaranteeing this for M4.
marking M5 and generalizing the bug title since the "UI block" is not really the issue anymore. I'm going to add more descriptive summary info to the update and install wizards, and as part of this I may look at sizing the unit rather than the individual pieces.
When doing this, the wizard code needs to be refactored so that the sizing happens before the wizard even opens. If the user cancels resolution/sizing, it's not easy to bail out in the middle of wizard creation. See also bug #212582 and bug #212607.
I've truly gotten off topic from Andrew's original bug, but since this bug now addresses "summary info" in the update/install dialogs, here we go. Two kinds of summary info to provide in the update/install dialog: - what is shown when something is selected (not checked). ie, show the description of the IU, etc. Could be shown in a details area. - what is shown to summarize all the checked items (ie, do we resolve and size when what the user checks in the dialog changes, to recompute a total size, and make sure that what is checked can be installed together?)
It was mentioned during a meeting today that we will probably have an "update description" which would be appropriate for showing in >- what is shown when something is selected (not checked).
When an IU is selected in the install wizard, show its description. When an IU is selected in the update wizard, show the description in the (new) IUpdateDescriptor, and if there is no description of the update, fall back to the description of the IU itself.
Fixed in HEAD. The uninstall, install, and update wizards have been updated to include a details area and also to do resolution as you check/uncheck the IU's in the wizard. - When an IU is selected (not checked), the details area shows its description. If we are in the update wizard, the description in the IUpdateDescription is shown rather than the IU description. - Whenever the user changes the check state of any IU in the list, a new resolution is performed (progress shown in the wizard) and the wizard finish will be disabled if the provisioning plan is no longer valid, with the status message reported in the wizard page's message area. - When the user presses finish, the last computed provisioning plan is used. Note that if the user never changed selections, then we use the plan computed before we ever launched the wizard. This eliminates the "extra resolution" that was being done just prior to running the operation. Note that I decided not to compute the total size as part of recomputing the validity of the plan when the user changes the checked iu's. This is because users may get confused if the total is different than individual sizes, and there wasn't a good place to show it. If we later decided to show a special area in the wizard describing the proposed plan (such as size, or customized reporting of plan errors), then we could do this.
