Community
Participate
Working Groups
The progress monitor in the software updates dialog does not have information about what is actually occuring. We should automatically close the dialog on install/update/uninstall so that the user can see the more informative monitor from the progress view.
The buttons that initiate these actions open a wizard first. We could simply close the update and install dialog and launch the wizard. If the user cancels, then they would have to reopen the update and install dialog. We need to look at a button arrangement that will help separate the "heavyweight" buttons that will close the dialog from the lighterweight buttons that just open auxillary dialogs such as properties, manage sites, etc... Perhaps put the heavyweight ones first, then some space, then the others? Kevin, can you comment if there's a convention already used elsewhere for this?
Discussed this with Kevin. After walking through the scenarios, he agrees that (a) it is a good thing for us to close the software updates dialog before launching the wizard (b) the install button (and update, uninstall buttons on the installed feature page) should be visually separated with a space between those buttons and the rest (c) there are some button ordering changes but since they aren't directly related to this bug I will add them in bug 229364
(In reply to comment #2) > Discussed this with Kevin. > After walking through the scenarios, he agrees that > (a) it is a good thing for us to close the software updates dialog before > launching the wizard > (b) the install button (and update, uninstall buttons on the installed feature > page) should be visually separated with a space between those buttons and the > rest > (c) there are some button ordering changes but since they aren't directly > related to this bug I will add them in bug 229364 (Sorry didn't have time to annotate this earlier, had to scoot out for a talk.) Yes to all that. They key for me was that in each of the actions you were pretty well guaranteed to be "done" once it completed (ie. I install, then go off and do some work). The one note though was that "Uninstall" as a non-blocking background process seemed kind of scary. What happens if I'm editing a java file and I chose to uninstall JDT? But that in a sense is a side issue since the current implementation allows that too.
>The one note though was that "Uninstall" as a non-blocking background process >seemed kind of scary. What happens if I'm editing a java file and I chose to >uninstall JDT? But that in a sense is a side issue since the current >implementation allows that too. yep, anything scary would only happen when the operation was done, you were prompted to restart, you felt lucky, and you chose to "apply changes"...then I suppose something scary could happen. Nothing will affect your running system, though, until that happens, things won't just disappear underneath you, like editors getting sucked down the drain.
Created attachment 100331 [details] patch to UpdateAndInstallDialog
(In reply to comment #4) >Nothing will affect your running system, > though, until that happens, things won't just disappear underneath you, like > editors getting sucked down the drain. Oh I like that. Perhaps its time to start the Eclipse Sound project... Makes sense, although niggle is user doesn't know scary things don't happen until they see the dialog later.
>user doesn't know scary things don't happen >until they see the dialog later. agree. >Created an attachment (id=100331) [details] >patch to UpdateAndInstallDialog I just attached a patch and then decided I don't like it because it closes the software updates dialog even if the user cancels the launched wizard. That won't fly. Need to do another patch that is more extensive. We now will need to know when the action is successful and close ourselves... Fix forthcoming...
Created attachment 100357 [details] patch to UpdateAndInstallDialog and ProfileModificationAction and subclasses this patch changes the actions so we know whether the action was actually completed.
John, can you please review this patch? It introduces a getReturnCode() method to the ProfileModificationAction so that clients can know what happened in the action. The UpdateAndInstallDialog will close itself if the wizard completes successfully. If the wizard is cancelled or the plan was not valid, and the user didn't ever open the wizard, the dialog stays open. The actions that will be affected in the dialog are the install, update, and uninstall actions. Note that the change to RevertAction does not affect the Revert used in the UpdateAndInstallDialog. The RevertAction that is changed is the one used by the admin ui when a rollback IU is already known. This means the dialog won't close when the revert dialog is finished (intentional - revert will force a restart anyway and there is no progress dialog being blocked.) This plays a lot better. The user immediately sees the "background job" progress dialog, and can dismiss it and keep working. The problem (and risk in releasing this change), though, is it really highlights how crappy our progress reporting really is, because now you get a nice job background dialog that can stay blank for quite some time. With the animating progress in the update dialog, at least you might feel like something is happening right away. Our users might perceive this as a regression if they never noticed that the software updates dialog progress was simply an animation. So we might want to rethink this if we aren't going to fix bugs like bug 225324. Can you discuss with Simon and Pascal whether we think we are going to have real improvements? I plan to address the accompanying button layout issues in a patch for bug #229364 which covers other polish-related layout and text label issues in the dialog.
I spent quite awhile playing around with the fix in place, and I agree there are certain times when the progress dialog has a dead period at the beginning where nothing appears to be happening. Overall, we have progress for the collect, install, and configure phases, and I am seeing those messages in the progress dialog. There is just a dead space at the beginning where there is no progress that we need to improve. I'm not sure what's going on at this point. We could minimally improve by setting the initial message to something like "Preparing to install" rather than the dorky message that just says "Install". Overall, I think we should go ahead with the change, and we can tweak the progress if needed.
released to HEAD for I20080515
I tracked down the cause of the long pause at the start of the install operation. Entered bug 232422.
