Community
Participate
Working Groups
Eclipse 3.4M6 features a new Software Updates and Add-ons tool that supposedly replaces 3.4M5's Software Updates->Find and Install and Software Updates->Manage Configuration tools. Usability of the new extension manager is severly degraded compared to the old Manage Configuration tool. First problem is time and click count that's necessary to install features from local folder. Here's what happens when user wants to install extensions from local folder in 3.4M6: 1. Enter Help->Software Updates->Available Features tab->Manage Sites 2. On Update Sites window click Add->Local->choose directory->OK 3. Click OK on Update Sites window (takes time to refresh the list) 4. Expand Others tree branch 5. Select all features 6. Click Install 7. Confirm installation on separate window (takes long time to appear) 8. Confirmation window disappears and user is back at Software Updates and Add-ons window. Since Eclipse is doing something in the background (CPU usage 100%) clicking Close button needs to be repeated several times to succeed. 9. User has to wait for the installation to finish (takes long time to finish). Compare that to 3.4M5 extension installation: 1. Enter Help->Software Updates->Manage Configuration 2. Right click->Add->Extension location->choose directory->OK 3. Restart confirmation window appears, click OK Installing e.g. WTP and Subversive with 3.4M5 takes less than 30 seconds (including all the clicking and Eclipse restart). With 3.4M6 it takes slightly more than two **MINUTES** and a LOT of clicking to achieve the same result. Not to mention 3.4M6 manager is SO unintuitive I had to go ask on IRC for help to even install anything at all. Overall, it took me more than an hour to install my extensions with 3.4M6 (learning the UI, resolving dependency issues, killing and reinstalling Eclipse, asking on IRC etc). There's another problem that for extensions that doesn't work with 3.4M6 unselecting potentially problematic ones from tens or hundreds of features to choose from is next to impossible. I stumbled upon such problem with Subversive which Mylyn integration doesn't work with 3.4M6. I had to remove my 3.4M6 install altogether and start fresh with Subversive to be the first thing to install to be able to properly deselect problematic features. Third problem is that when user is presented with a window to review features to be installed and click Cancel CPU usage jumps to 100% (Core Duo 2GHz, 100% on both cores). CPU usage drops shortly for flawless installs but for those with dependency errors it stays at 100% and Eclipse has to be killed to fix it. Eclipse 3.4M6 (I20080330-1350)
>Third problem is that when user is presented with a window to review features to be installed and click Cancel CPU usage jumps to 100% (Core Duo 2GHz, 100% on both cores). This is caused by bug 221087. As for what you see in the installation of extensions, you are experiencing the new behavior. With p2, the extension locations are being treated like an update site from which you install. Therefore you have to select what you want to install from this source, and like from any update site, there is no guarantee that selecting everything will install fine. For enhancement in this space I would recommend you to open a new bug report. Thx
Max, Sorry your initial experience was so disappointing. The problems you report are a mixture of UI workflow issues and underlying conceptual changes between p2 and update manager. There are some areas where p2 doesn't have a conceptual mapping to update manager (such as Pascal mentioned...extension location folders are just another kind of site) or its resolution strategy is stricter than UM. The intention is to reduce the click count for the most common operations. It seems we fail with extension locations but generally reduce the click count involved in the "Find and Install..." workflow. I'd like to focus this bug on specific ui workflows so that I can look at doing something about them. >1. Enter Help->Software Updates->Available Features tab->Manage Sites >2. On Update Sites window click Add->Local->choose directory->OK >3. Click OK on Update Sites window (takes time to refresh the list) Alternatively you can drag a folder from the file system or a URL on a web page to the available features dialog. In a "site-based" view of the world on that page we could put the add button on the available features page to reduce the click to the manage sites dialog. (bug #216028). >4. Expand Others tree branch This is an annoying click. I'd like to think I could expand everything after you add a site, but the performance is problematic. However in bug #216028 we are talking about alternate views, such as filtered/flat, by repo, etc. In a "group by repo" view it would make sense to auto-expand the repo so you don't have to click further. I've updated that bug to mention it. >5. Select all features >6. Click Install >7. Confirm installation on separate window (takes long time to appear) >8. Confirmation window disappears and user is back at Software Updates and Add-ons window. Since Eclipse is doing something in the background (CPU usage 100%) clicking Close button needs to be repeated several times to succeed. >9. User has to wait for the installation to finish (takes long time to finish). You can continue working (installation is in the background) but I guess your point is that you are waiting for what you need to finish so you can work with it?
(In reply to comment #2) > >4. Expand Others tree branch > This is an annoying click. And that was exactly the step where I needed to ask for help. 'Others' tree just doesn't look like a place to look for newly installed features so much that I didn't even bother to check it out ;) > I'd like to think I could expand everything after > you add a site, but the performance is problematic. However in bug #216028 we > are talking about alternate views, such as filtered/flat, by repo, etc. In a > "group by repo" view it would make sense to auto-expand the repo so you don't > have to click further. I've updated that bug to mention it. Thank you. > You can continue working (installation is in the background) but I guess your > point is that you are waiting for what you need to finish so you can work with > it? That too but most importantly working is pointless because: - it doesn't take _that_ long to start working on anything seriously - the performance is degraded so it's best IMHO to just leave the thing running :) So while it's true that background install is very useful for remote installs it's rather useless for local installs - disks are spinning and CPUs are heating up so why not just let it finish as quickly as possible? :) Summarizing -- from the point of view of someone who uses local extension folders exclusively (I'm on a rather slow connection and like to update Eclipse rather often :) ) the ideal way of doing that would be: 1. enter Help->Software Updates 2. Manage Sites->Add Extension Location->choose directory->OK 3. 'Install new features and restart?' window appears (it would appear for local extension folders only), click OK. If user wants to select individual features it's possible to answer 'No' and continue the usual way -- selecting, installing etc. I suppose that due to the underlying changes it's impossible to skip the 'Download/Install feature' part (or make it faster) but if that's actually possible it would be perfect. The point is to restore 3.4M5's way of adding local extensions folder without disrupting the existing UI. Most important suggestion is to skip the features selection/installation part. Local extensions folders are usually fine-tuned to user's needs (seen that in several companies, there's sometimes even a policy that all programmers have to install all the features from a given folder) and I think it's reasonable to expect that user just wants to install the darned thing and be done with it :)
I've renamed this bug to focus on your main issue, a streamlined extension folder UI. I think the other issues wrt selection, bolding, etc. are covered in the other bug. The performance degradation you are seeing involves changes to the underlying model. For example, some "new work" involved is that metadata that p2 understands is being generated for the extension location. There are a lot of performance investigations going on, so I expect things to improve incrementally. I am marking this for 3.4 to stay on my radar, but at this point can't say for sure what will happen. We are pushing for feature completeness for M7 and trying to polish/fix issues with the UI that is there. Just curious...if you could have dragged the folder to the installed features list and voila, the install began, would that be good enough?
> Just curious...if you could have dragged the folder to the installed features list and voila, the install began, would that be good enough? Interestingly, while thinking about the problem I ended up to the same conclusion. Maybe it is something that needs to be guarded by a preference though.
(In reply to comment #4) > The performance degradation you are seeing involves changes to the underlying > model. For example, some "new work" involved is that metadata that p2 > understands is being generated for the extension location. There are a lot of > performance investigations going on, so I expect things to improve > incrementally. Wonderful! > Just curious...if you could have dragged the folder to the installed features > list and voila, the install began, would that be good enough? Well, that would be better than nothing. But... the extensions folder isn't something used daily so user is unlikely to have it opened or bookmarked. Dragging a folder to the installed features list would involve opening Explorer/Nautilus/Konqueror/etc., navigating to the folder and then dragging it... I don't know about others but IMO it's easier/faster/more obvious just to have 'Add Extensions Folder' button.
(This message is part of a bulk bug update.) Removing milestone. We are feature frozen for 3.4. These were good ideas but are simply out of time and need to focus on stability.
removing milestone, this is deferred in the 3.5 plan.
bulk update: UI bugs not yet assigned a milestone are returned to the inbox.
*** Bug 86590 has been marked as a duplicate of this bug. ***
See also suggestions from bug #86590.
