Bugzilla – Full Text Bug Listing
| Summary: | [ui] Installed Software list should provide more organization/nesting | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Ian Bull <irbull> |
| Component: | p2 | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | david_williams, eclipse, gabriele.garuglieri, jeffmcaffer, karasiuk, Markus.Milleder, mober.at+eclipse, pascal, samuelwu, soloturn, stephan.herrmann, susan, tom.seidel, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | 3.5 M4 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 218055, 233269, 246875 | ||
| Bug Blocks: | 247342 | ||
|
Description
Ian Bull
This is by design (see bug 223920 comment 16). We can keep this bug open to track discussion. We believe this actually makes more sense for an end-user who doesn't understand the implementation details of the UM delivery model. However, it will certainly throw a particular set of users for a loop, so we may need to find ways to improve this. Also note that the list of features is still available in the about dialog. *** Bug 232211 has been marked as a duplicate of this bug. *** I'm sorry that I'd rather think this is a bug. In the UM, it lists the installed features, GMF in this case and included features, EMF and GEF, and nests them. It tells the user what have been installed and why. It also provents the user from removing something that are depended on by other features. The current flat list in p2 is very confusing. From usability studies it turns out that the list is less confusing because it hides the implementation details. The user installed GMF, it does not care about the rest. Some of the corporations have very strict policy on software installation. They want to know what are installed and why. I couldn't see why an expandable list would cause usability issue. For the users who don't care about the installation details, they can just leave the list collapsed. Note that there is much more detailed information about what's installed under Help > About. About dialog doesn't tell you the reason the feature is installed. That's what the customer wants to know. RCP products had an issue with the level of detail shown to the end user. Obviously, SDK developers are wanting more. I think the right answer in the long run is to make this configurable, not necessarily by end user preference, but by the application in whatever way makes sense. Different users care about different detail. Our first cut was to keep it simplified rather than showing everything we could. Note that what is shown in the "installed list" is very simply driven by a pluggable query, so RCP products today can alter what is shown, and we could change the query used in the SDK. One of the challenges is how far to drill down, there needs to be nesting if we are to show everything that is installed. For example, for the SDK, we could consider marking things roots if they were viewable as available when added. This is a bit odd since it is producer-driven as to what is important to the user. The answer is not straightforward here, but I agree that we will need to be more flexible in the future, and the good news is that the UI code is set up to show whatever is defined...the hard part is figuring out the best way to show it for different kinds of users. Since SDK developers are much more familiar with eclipse and all the processes including installation, I would think the end users convenience is of much higher priority. Is there a user bug opened against the expandable feature list in the UM? I just don't get it why the current list is better than the expandable one in the UM. >Is there a user bug opened against the expandable feature list
>in the UM? I just don't get it why the current list is better than the
>expandable one in the UM.
I understand that you don't think it's any better. We don't use a feature model underneath in p2, although we have some concepts we could use to try to simulate this kind of tree. At this point it's simply a matter of time, and you can be sure we are listening to your input and others as we evolve the UI.
Thank you, Susan. In bug 232484, the list is way too big (everything was marked as an install root). Nesting would help, if we showed a dependency tree like UM, but we may also need to investigate providing filtering in this view. Suggestions copied from bug #232800: In a large installation, the "Installed Features" tab list becomes so large that it's easily unusable -- especially because it doesn't only display the installable "root features" but also some "child features" which cannot be uninstalled by themselves anyways. The tab should show the installed features as a tree rather than a list. I propose that 1. The root nodes of the tree should be the features' configured update sites (makes the view consistent to the "installable software" tab and provides an additional grouping similar to what's requested in bug 198941; 2. On the 2nd level, there should be the "root features" which are not themselves included in any other feature; below each "root feature", the included child features should be listed. "Conflicts", e.g. root feature from update site A but included child feature from update site B, the algorithm should first determine the full list of root features independent of update sites, and then group the root features by the update site specified within them (i.e. the update sites specified in any child feature are not considered at all). I also propose that the root nodes detected by this algorithm (i.e. the configured update sites detected from the root features) should be mapped to auto-generated group IU's as per bug 224145 comment 9. I further propose that in the absence of real extension locations, these auto-generated group IU's should be mapped to what an extension location was in the pre-P2 era, for the sake of grouping features in views such as the PDE Target Platform View (see bug 224145 comment 5, and bug 224145 comment 15). A dropdown control similar to the "Available Software" tab should allow switching back to the current presentation of features listed alphabetically, but the auto-generated group IU's should be available none the less. I'm marking this issue "major" because bug 224145 has been perceived as one of the major problems adopting P2, and I agree that finding the right feature(s) for (de)activation in the "installed software" tab or the "target platform" control is currently close to impossible in a large installation. *** Bug 232800 has been marked as a duplicate of this bug. *** I think that the bug here is perhaps not so much whether we see a flat list or not, the bug is what's considered as an install root. In my case, all the add-on features are brought in through *.link files pointing to various pre-existing extension locations, and what P2 does is mark each and every feature it finds therein as an install root. I think that in case some features are brought in by a method like dropins/ or links/ which does not involve the user manually selecting something to install, P2 should be smart enough to mark exactly those features as install roots that are roots, i.e. that are not included as sub-feature within any other feature on the features currently being added. In my opinion, the missing categorization for stuff being brought in via links/ is a bug, which actually renders the view unusable, and not an enhancement request. In our commercial offering which is comprised of lots of features and plugins, we're currently also using *.link files to compose the entire installation (though that may change). How can we tag (or untag) something as install root in our custom Eclipse Product? It looks like my problem is actually a bit different than the original description on this bug, in that I'm experiencing exactly the opposite problem of what the original submitter saw (too many features and not too few). I didn't realize you were talking about dropins content when I said in bug #232800 >This is most likely a bug/misunderstanding in the way p2 is used in the build >process of the installation you are using. Opened bug 232843 for the issue of how p2 is marking the roots for things it finds in dropins and links. Maybe this why WTP has the same problem in bug #232484. >It looks like my problem is actually a bit different than the original >description on this bug, in that I'm experiencing exactly the opposite problem >of what the original submitter saw (too many features and not too few). Yes, I'm seeing bugs from both sides (too much vs. too little) and this bug represents the UI enhancements needed to find the middle ground between the short list and all the detail shown in the about dialog. Thanks Susan. Note that a good algorithm for finding the root IU's would also help the about dialog find proper descriptions for the icons there, see bug 198941. For the "too few entries" issue, I agree with the original reporter of this issue that a tree of additional items below a root IU will be less confusing than just seeing the root IU without the items it is comprised of. I do not consider this an "implementation detail". Since some child IU's may be full-blown frameworks by themselves. Whatever drill-down view of the installed software that we adopt should also be adopted in the install and update wizards. Right now we have this odd mismatch where we show licenses for things underneath but nowhere else do we explain why this stuff is being installed. For example I installed "Eclipse BIRT Report Designer XML Tab Editor" and the license list included most of data tools platform, EMF, WST. *** Bug 236366 has been marked as a duplicate of this bug. *** (In reply to comment #1) > This is by design ... > I know I've ranted plenty on this (and other) topics but if you will indulge me one little bit more ... One of the process break-downs, IMHO, is that much of this design (and others) went on with out any awareness, feedback, or education of us other Ganymede (and product) developers. Your designs effect our designs. If we understood some of these issues early enough, we might have changed our feature designs, etc. And, I know ... there's only so many hours in the day ... but, it seemed worse than usual this cycle, and especially in this provisioning area. I think some people have a certain mental model of what a feature is, what's installed mean, etc., but it's not understood by the rest of us. Could there be more "cross-project" coordination or education in the future? (I honestly don't know ... and doubt this is the bug to discuss it in ... but seeing "this is by design" just made me realize the degree of this lack of cross-project education on something which so obviously needs it (at least, obvious in hindsight)). And, I honestly do like much of what I'm learning about P2 ... I'm just raising the "meta issue" of cross project work, and hope someone can point me (and others) to the right channels for future improvements in process. Thanks. David, This bug represents how we show what is installed. It may seem easy to say "what's installed is what's installed" but even in 3.3, we had differing views and levels of detail of this in the About dialog, UM manage config, etc. The users/products that weren't satisfied with the level of detail UM forced on users wanted a simpler model..."what's installed is what the user chose to install" with hiding of detail. In hindsight, we may have swung too far in the other direction, but the good news is that the underlying code makes it pretty simple to plug-in different definitions for "what's installed." As far as the general issue of cross-product/project communication. There was/is plenty of communication via bugs, mailing lists, Equinox summit, wiki, etc...But until p2 was integrated into the SDK and therefore consumed by downstream projects, it was not obvious to observers what impact these discussions and decisions would have on them. The integration into 3.4 happened late in the cycle, so by the time folks like you were opening bugs, we were approaching feature freeze, and so we were saying things like "this is by design" in order to focus on the defects in what we designed. From my point of view, we can now all take a breath, look at what we have, and make design improvements. (In reply to comment #22) > > From my point of view, we can now all take a breath, look at what we have, and > make design improvements. > Thanks for tolerating me Susan, and so patiently and politely :) I did realize after my last post that this P2 stuff was advertised as a two release effort, which I tend to forget, so, having forgotten, I read things like "working as designed" as "working as designed and that's final!" ... but you have corrected that misinterpretation on my part. While this bug "... represents how we show what is installed" where would the correct discussion take place about what is an appropriate "installable unit"? For example, going back to comment #0, I know we plugin developers sometimes expect to see "gef" and "emf", but I think those are things a normal end user should never see in an "installed" list (no more than they see "swt" or "jface") ... so, my question is, do you have advice on where and when to have that level of discussion? Thanks again, >but I think those are things a normal end user >should never see in an "installed" list (no more than they see "swt" or >"jface") ... so, my question is, do you have advice on where and when to have >that level of discussion? You are in exactly the right bug. Your statement sounds exactly like what we were saying when we decided to hide things that the user had never explicitly installed. When a user installs something, we mark it (we call it a "root") and that is what makes it visible in the installed list. We assume the users don't care about what's below. It gets trickier, though, because they may see something already installed (and hidden) in the available list and want to install it. "Hey, what's this JFace (or GEF, or EMF) thing, I want it!" Today we simply mark it as a root - it looks like a really fast install and now it's visible. But what if they pick a different version...why/how would they be warned of an upgrade or downgrade if they didn't even know it was installed? If we start out showing only what the user installed (which we do today), and we wish to allow a drill-down view into more detail (as UM users are used to having), then how to we distinguish the layers? UM uses a producer-driven model using feature inclusion. We don't currently have an inclusion model, just a requirements model. In comment #18 Martin said: >I do not >consider this an "implementation detail". Since some child IU's may be >full-blown frameworks by themselves. I think we can agree that the perspective of how important a particular IU is (it is a major framework or it is an implementation detail) depends on where you sit in the producer stack. This is one of the most important conceptual issues I want to tackle in the 3.5 UI, and so I really want help and input on this discussion. If it becomes too cumbersome to talk about this in a bug, we could also make it a topic in a p2 conf call or break out a separate discussion elsewhere. At the p2 UIWG walkthrough, one thing mentioned was "why not get rid of the feature and plug-in details" from the about dialog and provide this information in the installed view? This is implied in this bug and others, but I wanted to state explicitly that we should consider better integrating all of this information. *** Bug 240125 has been marked as a duplicate of this bug. *** Suggestions/comments from duplicate bug: >Expected: >- the wizard's "Install" page shows the dependencies that are being pulled in, >and from what repositories (I don't care about the mirror). The page should >also note the total download and install size of all the dependencies. >If this creates too much clutter on the "Install" page, the plug-in dependency >details could be moved to their own page, which could be skipped by selecting >"Finish", or the list of installed items could be a tree with "plug-in >dependencies" a collapsed top-level item... <snip> >But then again: If I understand correctly P2 was created to also smoothly >support meta update sites that provide plug-ins from multiple sources, such as >a "plug-in central repository". In that case I would definitely want to know: > >- what's being installed >- who's the provider / creator >- under what licence >- under what copyright >- whether signed or not *** Bug 232484 has been marked as a duplicate of this bug. *** Just to add my 2c. p2 is a provisioning platform. Many things are possible. What you see in the SDK etc is one possible rendering of the meta information. indeed meta information itself is one possible representation of the artifacts. There is no design reason, for example, that someone could not create their own metadata with additional/different information and point their consumers at that. Similarly, the UI elements are designed to be composeable so product producers can position installable things the way they want with (hopefully) little effort. Susan is right on when she talks about things being relative to where you are in the producer/consumer stack. Everyone thinks their stuff is the most important, should be installed, should be sorted just so, ... What we are trying to do here is get the infrastructure/mechanism out of the middle and have it facilitate these requirements by allowing people to plugin on both sides. We are not all the way there yet. Having said all that, it would be way cool to consider ways of having someone plugin a sorter/organizer that would help the UI present the metadata to the user. This gets p2 further out of the middle and lowers the bar for people customizing this aspect of the presentatoin. it would be already a big help if the description could be shown additionally to name and version, and a search box provided to look for an installed feature. Responding to a few comments at once: >Having said all that, it would be way cool to consider ways of having someone >plugin a sorter/organizer that would help the UI present the metadata to the >user. We are partway there today, in that clients can specify an IQueryProvider which is responsible for providing the UI elements for queries such as AVAILABLE_IUS, INSTALLED_IUS, etc. The SDK's implementation of this provider answers the "explicitly marked roots" for this query. Another implementation could answer all IU's, or could answer the same top level elements, but with children that are the required IU's. The intention here is that any app can plug in a query provider that can traverse the installed content (and the available repo content) in any manner that makes sense. >it would be already a big help if the description could be shown additionally >to name and version see bug 236097 >and a search box provided to look for an installed >feature. do you mean a filter box where it narrows the list based on content (as in the available software list) or something different? Per comment #25, we are looking at ways of integrating p2 info with the info already in the about dialog. adding a dependency on bug #246875, which tracks the platform UI side of this work. See also this wiki page for discussion of workflows for integrating about. http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows#About However please note that the mockups are more about workflows for how one gets to the install info rather than the additional problem in this bug which is how to drill down and see more dependency info in the p2 view of the world. What we are thinking is that the user could easily switch between plug-in detail, feature detail, and the p2 view. We still realize that the p2 view should include some drill down from the install roots to the other things required (as should the install wizard itself). This bug will be addressed in M3 as part of the new workflows Adding another 2c. I agree that a tree showing dependencies is the proper way to enable drill-down. I think that any of the following top-level list may be what is expected/useful - and I'm talking about 'features' even if those are not exactly p2 concepts * Features that nothing else depends upon - "top-level" features. (What could I uninstall/disable without affecting anything else) * Features that the user (installation creator in managed installs) has explicitly installed - what p2 currently shows * "Public" features - features that are commonly advertised on the web. This means e.g. showing EMF, GEF (which are well known to people more versed in Eclipse), but not e.g. XSD (should be in EMF, as long as the EMF all-in-one download stays popular) or Zest (in GEF). This looks like it would need an extension of the feature metadata. * All features - this is mostly the About - Feature Details list, but I'd like to additionally have the dependcy drill-dwon a tree enables. * All "extending" features. In addition to the normal features extending the functionality of Eclipse, there are source features, documentation features, example features and test features. IMHO those additional types would be best represented as extra columns in the feature list - they aren't too useful on their own and contribute greatly to the total length of the list in SDK installs. Just a cross-reference re the original post, which mentions the difference between implicit installation (due to inclusion from an umbrella feature) and installation by explicit request: bug 244841 gives a scenario where this difference not only yields different display but also different behavior (here: inability to update by selecting only the umbrella feature). *** Bug 250189 has been marked as a duplicate of this bug. *** Some work has been done here. - The "Installation Information" dialog is integrated with some experimental API for contributed About dialogs. Bug #246875 describes the details about how plug-ins can contribute pages to a common about dialog. The p2 Installed view is now implemented in terms of that dialog and available in a temporary menu item called "Installation Information..." When Bug #246875 is completed, this dialog will launch via Help->About and that menu item will go away. This is available in the 20081014 I-build. - The items in the Installed Software Page of this dialog are now shown in a tree. The children of the "root IU's" are those IU's required by the IU and visible in the available software list. This is not in today's I-build, but will be in tonight's nightly build and the 20081021 I-build. Remaining work: - see if the traversal described solves most user needs - integrate into the about dialog - decide if the feature view of the about dialog is needed anymore (we may be able to drop that now and simply show the Installed Software view and the detailed plug-in view). Now that I'm in the thick of this work, it's clear that drilling down into detail in the wizards (vs. the main install view) has different dependencies on core. So I've opened bug 250862 to discuss the wizard traversal separately. This bug now deals specifically with what we are showing in the installed software page. (In reply to comment #37) > Remaining work: > - see if the traversal described solves most user needs Ian, David, Samuel, and others - I would appreciate your feedback on this issue. In this week's I-build (and of course in M3) you will be able to traverse the requirements chain in the install dialog. > - integrate into the about dialog > - decide if the feature view of the about dialog is needed anymore (we may be > able to drop that now and simply show the Installed Software view and the > detailed plug-in view). This will be done in the context of bug #246875. Reassigning this bug to M4 to allow time to respond to feedback on the drill-down traversal. (In reply to comment #39) > (In reply to comment #37) > > Remaining work: > > - see if the traversal described solves most user needs > > Ian, David, Samuel, and others - I would appreciate your feedback on this > issue. In this week's I-build (and of course in M3) you will be able to > traverse the requirements chain in the install dialog. I haven't received any feedback over the past month(negative or positive) about the drill-down view apart from bug 252366, which is now fixed. So I'm going to assume that new bugs will be opened if there are cases we are not covering. > > - integrate into the about dialog > > - decide if the feature view of the about dialog is needed anymore (we may be > > able to drop that now and simply show the Installed Software view and the > > detailed plug-in view). > > This will be done in the context of bug #246875. The decision here is that we are trying to replace "feature details" with the p2 view and integrate the p2 installation information dialog into a platform UI plug-in, with p2 contributing the actions/buttons. That work is being done by Kim in the context of bug #246875. > > Reassigning this bug to M4 to allow time to respond to feedback on the > drill-down traversal. I'm going to mark this bug FIXED. Note there are other bugs for specific other suggestions (such as copy/paste from install view, etc....) verified on WinXP, Build id: I20081209-0100 |