Community
Participate
Working Groups
Build ID: I can make the tree work by selecting "" Steps To Reproduce: 1. Download RC2 2. Select "Help" -> "Check for updates" 3. The wizard will present roughly 200 plugins to update. Select OK. More information: In the progress view, you can see a single item which flickers a lot. I can read "operations is blocked by background process". It also seems to download several files at once but the whole visual effect is ... ugly. The 3.4 version would open a single item in the progress bar per download and you'd have a parent item with the update progress. That looked much better.
What you see in #3 is the result of how you initially laid out your plug-in in the first place. To have that many things you either have installed everything in galileo, or used dropins. Right now p2 shows you the roots that you've decided to install and that are updatable. If you have concrete suggestions on how to improve please open a particular bug about it. In the meantime I'm refocusing this bug on the download flickering.
Correct, the number of downloads is not the issue. The ugly flickering must go :)
This is also related to Bug 263600 - (progress is not reported smoothly). The flickering progress bar is really just a symptom of something else not being done right - there are several threads performing download, but when expanding the dialog, there is almost never more than one sub-progress bar. I would expect the overall progress bar to say something like "Updating", "Installing" or similar, and that there were subtasks like "Downloading artifacts" - in turn broken down into the different threads performing downloads.
This has been driving me crazy lately while testing and I finally decided I had to fix it. There are two main issues that make the progress look bad (to me): 1) The "wait for background work" messages that keep flickering. This happens because we have two jobs, and one waits for the other via join(). The join() method reports the blockage to the progress monitor, which replaces the progress task message with the ugly blockage message. In many cases this is useful, such as when the UI is blocked unexpectedly by some background work, but in this case it doesn't provide any extra value and is just distracting. 2) We never provide a meaningful top level task message for the ProfileModificationOperation instances. This means it inherits the generic "Operation in progress" message that doesn't give the user insight on exactly *what* operation is in progress. I have fixes for these two issues (patches to come), which make the progress during install/uninstall/update look much better to me.
Created attachment 147009 [details] Fix for issue #1
Created attachment 147010 [details] Fix for issue #2
I have released #1 to HEAD, but moving to Susan to review fix for #2. This was a quick & dirty change but you may prefer passing the messages in the operation constructor like it's done for the job label. I did it this way to make it "optional" to avoid having to make too many changes.
After talking with Susan briefly I've released my patch #2 to HEAD. I was a bit worried about losing it during branch/merge over the next while and wanted to get it out of the way. It's not risky and it does improve progress messages.
(In reply to comment #7) > I have released #1 to HEAD, but moving to Susan to review fix for #2. This was > a quick & dirty change but you may prefer passing the messages in the operation > constructor like it's done for the job label. I did it this way to make it > "optional" to avoid having to make too many changes. I looked over the changes as they came in. I had a very similar issue in bug 274876 (code is in my workspace) where I define a new getter/setter on the operation and did not modify the constructor. I think it's quite reasonable to do this, especially since there is a reasonable default.
Verified on WinXP, Build id: I20091027-0100 The top level progress messages are showing.
