Community
Participate
Working Groups
Eclipse 3.4 RC3 I was trying to install both EMF and Ecore tools using p2. 1. I opened the available software 2. Searched for EMF 3. Selected EMF SDK 4. Searched for ecore tools 5. Selected Ecore tools 6. Hit install Only ecore tools was going to be installed (note that EMF was currently filtered). If I clear my selection box before hitting install, they both install fine.
this is a known limitation that could perhaps be argued to be a feature, but it really is just the result of the implementation. You can clear and reset the filter to find selections, but it will always honor what is visible. See bug #229735 comment #7. Leaving this open because we might want to revisit the behavior when we develop a better solution for asynch checkbox filtering (bug #233269).
I battled pretty hard with this when I implemented the filteredcheckbox tree for the plug-in selection on the launch page. One option may be to disable the install button while there are items filtered. (Don't do this for 3.4) In the PDE I ended up having to keep a separate state of "checked bundles", and manage the checkmarks during the refresh. If we ever get around to fixing Bug# 220668, then we can address this issue here.
I think it would be wrong to disable the install button while filtered. If you press the button and realize your wizard is missing items that are filtered out of view, it's pretty easy to realize what you need to do about it. If the install button is disabled, well, you don't really know what to do next. I think the real fix will be bug #233269...taking the ideas from the PDE solution, from our solution, looking at data binding, etc. I'm going to work with Boris to try to get something that scales. I agree with him that trying to hack around what is there is really painful and bug-laden. I tried some of the other solutions (including your filtered checkbox viewer that PDE uses) but it didn't work. We have issues involving asynch retrieval of elements that are different than PDE's. PDE does asynch retrieval to do one initialization sequence and after that everything can be synchronous. In our case this is not true, and coupled with the accumulation strategy of DeferredTreeContentManager, we had tons of timing problems.
>In the PDE I ended up having to keep a separate state of "checked bundles", and >manage the checkmarks during the refresh. We do something similar, but because of various timing problems we had save and restore the checkmarks from the filtered tree/filter job rather than keep them in the viewer. That is why the viewer doesn't know about the checkmarks that aren't visible.
I think you'll get some users confused regardless of which approach you use. I think only installing what the user can see is safer, in that it won't install something they checked earlier but forgot they had checked. Since the install wizard will always preview what will actually be installed, the user has an opportunity to double-check and go back if they missed something. We had a similar debate in CVS about the various filtering modes in the Synchronize view, and decided only operating on what was visible had the least chance of surprise.
I agree that disabling the install button was a bad idea. Users may not know what to do to enable it, but (personally) I don't buy the argument that users would only expect to install the items they see. Quick filtering (through mylyn, text filters, etc...) is very common in the Eclipse UI, and I imagine that users will search for a number of different units to install, and not necessarily think to disable the last filter. (Unlike the CVS view, these are very light-weight filters) That said, I do appreciate that this has some hard technical challenges, (and could potentially confuse others) and the wizard page that previews what will be installed should help avoid confusion. I suggest we keep this bug open, but don't worry about fixing it (yet). If others think this is a problem, then we can address it. If I'm the only person that thinks this is a problem then I will close it as invalid. Susan, John, thanks for all the information.
Yes, I want to leave this open and make the decision intentionally rather than having it as an artifact of the implementation.
fyi, in bug 257597 I'm considering a "N items selected" label. This might help if we decide to change our mind on the selection filtering.
Note to self: if we revisit this, take a look at the new ICheckStateProvider provided in M4 in platform UI. This may allow us to stop using our copy of ContainerCheckedTreeViewer (and all the checkstate bugs that come with it) and instead just use a checked tree viewer and custom checkstate provider.
*** Bug 258461 has been marked as a duplicate of this bug. ***
*** Bug 275480 has been marked as a duplicate of this bug. ***
One thing the description doesn't mention is that the Group Items by Category is also affected by this (See the description in bug 275480 for the dance I had to do to install multiple features, some of which are grouped and some of which are not). If what John mentioned in comment 5 is true, then perhaps using check boxes is not the right answer here. Perhaps an approach like the one used by the PDE import wizard would be better. That is, you have two panes, one which shows the features that can be installed and another that shows those that have been selected. This takes up more real-estate but is less confusing for the user.
*** Bug 278275 has been marked as a duplicate of this bug. ***
I'm working on this now, but won't be putting anything in for M2.
Need to figure out what an unchecked [ ] Contact all software sites button behaves like in this model, where you aren't viewing "all sites" and you have selections from multiple sites. Ideally we would have a provisioning context that included only those sites from which selections were made.
(In reply to comment #12) > If what John mentioned in comment 5 is true, then perhaps using check > boxes is not the right answer here. Perhaps an approach like the one used by > the PDE import wizard would be better. That is, you have two panes, one which > shows the features that can be installed and another that shows those that have > been selected. This takes up more real-estate but is less confusing for the > user. My current thinking is that we'll have a status indicator like "16 items selected" and if you hover over that indicator you'll get a popup showing you everything you've selected so far. Note that when you press "Next" you get the confirmation list showing everything you had picked (and drill-down detail if you want to see what requirements will be brought in).
I think PDE reuses this dialog for target management. This might of interest to them too. CCing Chris.
*** Bug 309136 has been marked as a duplicate of this bug. ***
This is more than a polish item IMHO. Since PDE uses this in the target editor, the clearing of the selection when using the filter field results in the loss of user data. Elevating this to major.
(In reply to comment #19) > This is more than a polish item IMHO. Since PDE uses this in the target > editor, the clearing of the selection when using the filter field results in > the loss of user data. Elevating this to major. No data should be lost. For example (with I-build and Helios in my list of sites among others) Install New Software All Available Sites Type "rel" and select releng now type "acc" and select acceleo if you push "next" without clearing the filter you get acceleo only. If you go back and clear the filter, you get acceleo and releng. I agree this has usability issues but data is not lost. I'd really like to reexamine this in a larger context. Having the double filter of site and then filter text is pretty confusing, and the filter by repo does not exhibit consistent behavior with the text filter.
(In reply to comment #20) > No data should be lost. For example (with I-build and Helios in my list of > sites among others) > > Install New Software > All Available Sites > Type "rel" and select releng > now type "acc" and select acceleo My comments relate to PDE Target Platform management workflows. When you are installing software the profile has the list and it is essentially an additive operation. In that case, I agree, no data loss. Curtis closed Bug 309136 as a dupe of this one. Check out the workflow described there. In that case you are EDITING the target. That is, it is not additive. The target elements for that site are initially checked. You use the filter to find and add antoher. Click Finish and, well, all your other data is lost because the target was edited. If the flow was "what do you want to *add* to the target" then it would he like installing. > if you push "next" without clearing the filter you get acceleo only. > If you go back and clear the filter, you get acceleo and releng. > > I agree this has usability issues but data is not lost. You could argue that this is a just a usability issue and all users of the dialog should always clear the filter before clicking finish but if all users have to do that all the time in order to not lose data, it seems like a problem that should be fixed. (obviously I have exaggerated and there are useful flows where you have nothing, filter, select something, click finish and are happy. I suggest that that flow is far from the norm. Users edit their target def many more times after initial creation) > I'd really like to reexamine this in a larger context. Having the double > filter of site and then filter text is pretty confusing, and the filter by repo > does not exhibit consistent behavior with the text filter. Agreed however every single time we show people the target definition workflow in tutorials, courses and demos, this bites us and we have to say "don't use the filter field".
(In reply to comment #21) > My comments relate to PDE Target Platform management workflows. When you are > installing software the profile has the list and it is essentially an additive > operation. In that case, I agree, no data loss. Since this workflow keeps causing issues (see also bug 272725) perhaps I can look (again) at tweaking the PDE workflow in bug 276214.
(In reply to comment #21) > My comments relate to PDE Target Platform management workflows. When you are > installing software the profile has the list and it is essentially an additive > operation. In that case, I agree, no data loss. > > Curtis closed Bug 309136 as a dupe of this one. Check out the workflow > described there. I see. It's a lot worse there. Whereas in this bug there was a reasonable debate about the user's expectations, I think when the same UI component is used to reflect an editing state, there's really no debate to be had. Should we undup the bugs? I feel your pain here, but my problem is that I'm maxed out with bugs/performance issues, etc., I don't have any cycles to look at usability issues at all.
(In reply to comment #22) > (In reply to comment #21) > > My comments relate to PDE Target Platform management workflows. When you are > > installing software the profile has the list and it is essentially an additive > > operation. In that case, I agree, no data loss. > > Since this workflow keeps causing issues (see also bug 272725) perhaps I can > look (again) at tweaking the PDE workflow in bug 276214. Just mid-air collided with Curtis. Curtis, if the PDE workflow change requires tweaks to the AvailableIUGroup and you can make a patch, I will look at it.
Seems like undup'ing would be appropriate. While I agree that PDE is just reusing p2 function, it is clear that the workflows are different. Over to you Curtis...
Ping. This is a P1 on the polish list. Any chance for 3.6 or at least 3.6.1?
(In reply to comment #26) > Ping. This is a P1 on the polish list. Any chance for 3.6 or at least 3.6.1? This is an annoyance, but discussion in this bug concluded that the PDE target definition workflow was the one with the more severe issue. (the same code is being used but for different purposes). Therefore I believe that bug 309136 is the one Jeff was referring to on the polish list. Jeff, please correct me if I'm wrong about this...
> Ping. This is a P1 on the polish list. Any chance for 3.6 or at least 3.6.1? I don't want to rush that. The population of the UI is already slow and doing this sort of verification will make it slower. On top of that it won't necessarily be precise as the filters get more complex. Ideally I think additional information is necessary so that what is used to determine what gets shown does not collide with what is used to resolve dependency. One thing to note is that in 3.6, the error messages to handle with the installation of a non matching IU has greatly improved, so it makes it easier for ppl to figure out what is going on. Btw, where is the list of polish items, and who put that on there and I did not know :)
(In reply to comment #28) > > Ping. This is a P1 on the polish list. Any chance for 3.6 or at least 3.6.1? > > Btw, where is the list of polish items, and who put that on there and I did > not know :) Jeff put it on there but he was really referring to the more extreme issues in PDE target definition, where it removes stuff from your target because of the filtering. In the install UI we don't remove anything, there is no harsh consequence (other than perhaps surprise/annoyance.)... I have never wanted to look at this for the install wizard without also considering the effect of the repository filter. If we install not-visible filtered items, do we also install not-visible items that were previously selected in another repo in the combo? In other words, it's a design issue, not just a "bug" to be fixed now or in a maintenance release.
I added this to the polish list when it was suggested that this was the root of the PDE target platform problems. I'm fine with moving the polish entry to PDE though it seems like the PDE team is not going to get to bug 309136... As for the polish list itself, its the list we do every year where committers can add items they find and think are particularly important for teams (any team) to look at. See http://wiki.eclipse.org/Polish3.6 or refer to the minutes of various PMC and planning meetings.
Damn, I just totally confused the issue with another one... Sorry about that. That'll teach me to only rely on the title of the bug rather than the description. As for the list itself, I must admit that I had not seen it, but I missed a few calls and must not have seen it on the ML.
*** Bug 316686 has been marked as a duplicate of this bug. ***
I have a fix for this that works in the 'simple case'. That is, if an item is checked and then hidden by a text filter, then it will stil be installed. If you switch to a different repository and start checking items, the items from the first repository won't be selected anymore. This should hopefully help in the PDE Target case since you usually create a new 'site' for each p2 repository you want. As for the visibility issue -- we are now installing things that are out of view, a user will still have the opportunity to review the list of items on the next page in the wizard.
This was fixed a while ago: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=cecf43ce5d7eb99d356a798afdecfee2a3910788
