Community
Participate
Working Groups
This is to disclose a possible implementation for common navigator purposes, an Others working set that dynamically assigns membership.
Created attachment 126616 [details] java file
Can you explain a bit more what the intention of this is? What should it do? Where would it be used?
This look like a modified copy of org.eclipse.jdt.internal.ui.workingsets.OthersWorkingSetUpdater. The Common Navigator has its own working set story -- not sure how this would fit in there...
This might be a dup of bug 196595
*** Bug 196595 has been marked as a duplicate of this bug. ***
*** Bug 268838 has been marked as a duplicate of this bug. ***
Hi Francis, you said either in your blog or platform UI mailing list that we need to use project explorer rather than package explorer. This issue likely blocks migration to project explorer. In the package explorer, there is an "Other projects" working set for projects not yet in a working set. The project explorer does not have such a capability. Once you enable working sets in the project explorer, all projects must belong to a working set. This makes it difficult to find projects that need to be added to a working set. Picture a workspace with over 100 plug-ins. I can turn on and off working sets, but I am not sure how to find projects not in a working set. In package explorer (and other explorers), this was accomplished by the "Other projects" working set.
(In reply to comment #7) need to use project explorer rather than package explorer. > > This issue likely blocks migration to project explorer. > Thanks for your comment on this, I will do this first for M7. It's good to have this perspective.
*** Bug 268167 has been marked as a duplicate of this bug. ***
Created attachment 133440 [details] First cut - has some issues Here is a first cut at the "Other Projects" working set. It has a few issues: 1) The icon "workset.gif" needs to be copied from org.eclipse.ui (or workbench -- I forget which) 2) It stores the "Other Projects" working set in the main working set manager, which matches things up by name. This will not work if a workspace changes locales (since the "Other Projects" name is localized. 3) There is a test for this in the working sets test, but they don't pass atm. 4) The Other Projects working set ends up being sorted in both the ProjectExplorer and the dialog to select working sets. In the package explorer it's always on the top (since it's special). The package explorer was is better. 5) Deselecting the "Other Projects" working set in the selection dialog does not cause it to not appear. It's clearly too late to try to get this into 3.5; and I think there are several other issues with working set support in the Project Explorer that should be addressed with this. For example, the dialog for selecting the working set comes from the base UI and that may not be adaquate to the task (JDT UI uses their own). So this is a start and will be continued for 3.6/e4.
*** Bug 295542 has been marked as a duplicate of this bug. ***
*** Bug 338677 has been marked as a duplicate of this bug. ***
The Project Explorer is also missing the Package Explorer's ability to drag projects between Working Sets.
(In reply to comment #13) > The Project Explorer is also missing the Package Explorer's ability to drag > projects between Working Sets. Would you mind filing a separate bug report about that?
(In reply to comment #14) > (In reply to comment #13) > > The Project Explorer is also missing the Package Explorer's ability to drag > > projects between Working Sets. > > Would you mind filing a separate bug report about that? I should have seen that coming :). I added it as bug 390348.
*** Bug 427889 has been marked as a duplicate of this bug. ***
Hwew is a suggested alternative implementation. In the "Select working set" dialog, have a checkbox after the list of working sets, with label "Use this working set as default" and a combo allowing to choose an available working set. When checked, the Navigator would show all projects that are not assigned to a working set into this working set.
Ongoing experiment at https://github.com/mickaelistria/eclipse.platform.ui/tree/266030 . Any help is welcome!
Gerrit patch https://git.eclipse.org/r/24803 aims at providing a similar fonctionality, with more control to avoid breaking existing users.
Note that change suggested by https://git.eclipse.org/r/24803 introduce a new method in an Interface of the API.
Since there is a review pending, couldn't this review be planned for 4.5? The issue with letting contribution pending is that they quickly become obsolete and it's not really motivating for contributors to keep on contributing if patches get ignored.
I'd really like to see this proposal at least evaluated to be integrated in Mars. Is there anyone who could have a look at it?
Is it possible to schedule this review for 4.5.M6 ?
Mickael, the patch seem to create a workingset called "default" instead of "Other" which is explicitly "anything that is *not* in a working set". I tried to check it out but no luck without alot of conflicts.
The suggested patch allow to select an existing working set as a default placeholder for projects that don't have a working set. It's not exactly the same approach as JDT, but it allows to do the same thing, and I believe it's a nicer implementation than showing something that is not a working set (Others) as a working set and forcing the name to "Others".
(In reply to Mickael Istria from comment #25) > The suggested patch allow to select an existing working set as a default > placeholder for projects that don't have a working set. > It's not exactly the same approach as JDT, but it allows to do the same > thing, and I believe it's a nicer implementation than showing something that > is not a working set (Others) as a working set and forcing the name to > "Others". I prefer to implement the same concept as in the 'Package Explorer'.
(In reply to Dani Megert from comment #26) > I prefer to implement the same concept as in the 'Package Explorer'. Well, that's a matter of opinion, so let's discuss ;) Why do you think a static "Others" working set is better for the user than ability to select a default working set? Note that to get the exact same behaviour out-of-the-box, we could think about providing an actual "Others" working set by default, and enabling it as target WS for projects that are not attached to any working set.
(In reply to Mickael Istria from comment #27) > (In reply to Dani Megert from comment #26) > > I prefer to implement the same concept as in the 'Package Explorer'. > > Well, that's a matter of opinion, so let's discuss ;) > Why do you think a static "Others" working set is better for the user than > ability to select a default working set? > Note that to get the exact same behaviour out-of-the-box, we could think > about providing an actual "Others" working set by default, and enabling it > as target WS for projects that are not attached to any working set. It will be easier for Project Explorer users when they have the same concept as known from years in the Package Explorer. And at this point we are not going to change the Package Explorer.
(In reply to Dani Megert from comment #28) > It will be easier for Project Explorer users when they have the same concept > as known from years in the Package Explorer. And at this point we are not > going to change the Package Explorer. I understand your point, but here it's a new feature in another explorer. It's the right time to make things better than they used to be. I don't think trying to mimic all features from package explorer without taking the opportunity to think of whether there is a better way to do it is a good approach. Project Explorer have space to become better than Package Explorer, that's something we should leverage.
I really do not think it is a good thing to force creation of a "special case" working set. It will change depending on what version of eclipse I use, it will *force* creation of workingsets even though I do not use them - and it will only happen if I actually have used the project explorer. I would definitely prefer it to be "Other" and that it is *not* a workingset that gets created.
Reason the current "Other" that is virtually calculated is better than "default" working set. A) does not need to change every wizard/UI element that has workingset as target B) does not need to actively listen to projects being added/removed to eclipse to maintain the "default" working set C) does not need to actively listen to projects being added/removed to workingsets to maintain the "default" working set.
D) does not introduce a new conflicting UI concept
btw. this concept should preferably be applied to *all* common navigator explorers so adopting what is done in Project Explorer by "Other" seems so much more straightforward and simpler.
If we go for the exact same approach than with Package Explorer, then we need to have the "others" working set optional, or we introduce a regression to what Project Explorer is able to do: show only the selected working sets, which I find pretty useful when doing demos as it allows to hide irrelevant things. Note that unlike some users, I'm using a single workspace for all my work, and I actively use working sets and hide some of them to "scope" my work, instead of switching between workspaces.
Package Explorer supports the exact same thing. You can unselect the "Other Projects" and it will not be shown.
How about not adding an "Others" working set but instead adding a checkbox in Edit Working Set... dialog labeled e.g. "Show also Projects not in any Working Set". This would then list all non-working set projects in Project Explorer's list below the list of working sets without grouping them, even with working sets set as top-level elements. Adding a horizontal separator line between these two groups might be a good idea too.
Created attachment 261135 [details] Image: missing working "Other Projects" Working Set in Project Explorer The "Other Projects", collects projects unlisted in other any working set. This feature is available in Package Explorer for a long time. We should add this also in Project Explorer, to make users happy, especially now that Project Explorer is the default in PDE for Neon. I use working sets 90% of the time, and without the "Other Projects" is impossible to view any project not included in one of the visible working sets. Consider this case: when you create a new project, usually you don't assign it to any working set. So, from Project Explorer, to have it visible, you have to switch to a different view; select the project; add it to one of the "visible" Working Sets. But, when you are in Package Explorer, you just need to keep the "Other Projects" working set active! IMHO it's a "must have", possibly for Neon!
(In reply to Patrik Suzzi from comment #37) > IMHO it's a "must have", possibly for Neon! I completely agree. After upgrading to Neon, I was getting ready to go back to Mars until I found this issue and realized they changed the default to "Project Explorer". As it stands, "Project Explorer" is unusable to me because of this issue.
(In reply to David Glodich from comment #38) As workaround, you can either use the Package Explorer view in PDE perspective or use the Java Perspective (which uses as default the Package Explorer)
(In reply to David Glodich from comment #38) > I completely agree. After upgrading to Neon, I was getting ready to go back > to Mars until I found this issue and realized they changed the default to > "Project Explorer". As it stands, "Project Explorer" is unusable to me > because of this issue. In case you're using working sets to group projects that are part of the same "tree", with Project Explorer, you can trigger the hierarchical project layout via the View Menu to have projects from the same hierarchy grouped without using working sets. Not sure it's helpful for your use-case though.
(In reply to Patrik Suzzi from comment #39) > As workaround, you can either use the Package Explorer view in PDE > perspective or use the Java Perspective (which uses as default the Package > Explorer) Yes, I'm using Package Explorer now - thank you. Just makes me wonder what features I may be missing out on, since Project Explorer is the "recommended" view now. ;-)
(In reply to David Glodich from comment #41) > Just makes me wonder what > features I may be missing out on, since Project Explorer is the > "recommended" view now. ;-) Try it and you'll see ;) For Java EE projects, WTP adds many "model" nodes showing endpoints and resources in project explorer that aren't visible with Package Explorer. Same thing for JavaScript, you'll miss the ability to browse the content of the files. You'll also miss the ability to show project hierarchically. Basically, many things that aren't plain Java are missing. I suggest that rather than using Package Explorer, you manually define an "Others" working set for Project Explorer, and put what you want in it. For many projects (maybe not yours), there is much value in Project Explorer that isn't accessible with Package Explorer.
(In reply to Mickael Istria from comment #40) > In case you're using working sets to group projects that are part of the > same "tree", with Project Explorer, you can trigger the hierarchical project > layout via the View Menu to have projects from the same hierarchy grouped > without using working sets. > Not sure it's helpful for your use-case though. I don't believe that works for my use-case. The only thing switching to a hierarchical presentation does for me, is change how my packages are laid out (e.g. makes me have to expand multiple folders to get to my classes.) It doesn't appear to affect the way my projects/bundles are organized at all. Maybe I'm missing something? My use case is that my team works with close to 300 bundles organized in close to 50 working sets. We organize our bundles into working sets to ease our ability to find closely related bundles while still maintaining visibility of our entire workspace (e.g. we don't use working sets as a "filter" which restricts the visibility to a specific subset of our workspace.) (Note: Package Explorer also allows you to rearrange the order your working sets are displayed in, which is very helpful/useful, while Project Explorer does not.) The "Other Projects" node is important, because we need to be able to see bundles that are not assigned a working set (e.g. we just created the bundle, someone has forgotten to assign it a working set, or it's a temporary/testing bundle for which I don't feel like going through the work of setting up a working set.)
There is a patch suggested https://git.eclipse.org/r/#/c/24803/ . Feel free to give it a try and check whether this would work for you.
(In reply to Mickael Istria from comment #42) > Try it and you'll see ;) > For Java EE projects, WTP adds many "model" nodes showing endpoints and > resources in project explorer that aren't visible with Package Explorer. > Same thing for JavaScript, you'll miss the ability to browse the content of > the files. > You'll also miss the ability to show project hierarchically. > Basically, many things that aren't plain Java are missing. > > I suggest that rather than using Package Explorer, you manually define an > "Others" working set for Project Explorer, and put what you want in it. For > many projects (maybe not yours), there is much value in Project Explorer > that isn't accessible with Package Explorer. I pretty much only work with eclipse RCP/java projects, so maybe I'm not missing much. ;-) To be honest, I usually don't like to expand my nodes past the file level in the Package/Project Explorer anyway - I prefer to use the Outline view to see any further detail. I'm not sure what the "show project hierarchically" thing is - maybe that's what I was missing from your earlier comment. I now see there is both a"Projects Presentation/Hierarchical" and a "Package Presentation/Hierarchical" option. The "Package" one is the one I was playing with before - the "Project" one does not seem to do anything for me... (If that where to work similar to the "Package" option for projects, then that might be pretty useful - though I'm not sure it would be preferable to the more flexible Working Sets functionality found in Package Explorer.)
(In reply to Mickael Istria from comment #44) > There is a patch suggested https://git.eclipse.org/r/#/c/24803/ . Feel free > to give it a try and check whether this would work for you. Thanks, I'll give this a try a bit later today.
To chime in, I was really glad to find this bug, because I didn't realize that Neon had swapped the "Project Explorer" as default in place of "Package Explorer". I was pulling my hair out trying to figure out how to show "Other Projects". I too expect/depend on "Other Projects" as I work with a sizable number of plug-ins. It's nice to know that you don't have a plug-in that has slipped your notice simply because you didn't add it to a working set.
I was about to file the same bug for the same reason. I wonder how many hundreds of hours have now been wasted by people trying to understand why behavior in Neon is different than Mars with only a single line in the N&N to give any clue! Please don't change things unless you can guarantee the behavior is the same, or at the very least make a VERY public statement of what has changed. You may not use a feature, but you can be sure that many users do!
New Gerrit change created: https://git.eclipse.org/r/81219
Removing reference to previous patch (which was overkill), see now https://git.eclipse.org/r/#/c/81219/ which only add a checkbox in the "Top-Level element" menu to decide whether to show "others" when top level elements are working sets. Technically, adding this involves 1. adding the right things to content provider 2. disabling the filter when we want to show "Others" or projects are still hidden. As this seems to be a blocker for many people interested in adopting the project explorer, I hope some of the interested parties can review it soon. As it's a feature addition without breaking any previous workflow nor API and all changes are part of internal packages, we might even consider it for 4.6.2 in best case.
I think it's important that it works and looks like it does in the Package Explorer. Unless you think the Package Explorer is wrong.
(In reply to Doug Schaefer from comment #51) > I think it's important that it works and looks like it does in the Package > Explorer. Unless you think the Package Explorer is wrong. Did you try the last patch?
(In reply to Mickael Istria from comment #52) > (In reply to Doug Schaefer from comment #51) > > I think it's important that it works and looks like it does in the Package > > Explorer. Unless you think the Package Explorer is wrong. > > Did you try the last patch? No, I don't have the platform source checked out. I just saw "Others" and it's "Other Projects" in the Package Explorer. Minor detail, but it got me wondering. The main thing is that it shows up in the list of Working Sets and you can turn it on and off there. That looks like what you're doing, I think.
So you'll notice it doesn't work the same, because Project Explorer working set can also be used as filters (Which they are not in Package Explorer). As we cannot remove features from Platform UI, we have to stick with the "filter" part of Project Explorer. In Project Explorer, working sets enablement can also affect the content you see when you're not using Working Sets as root. We cannot at all simply mimic the JDT behavior, so we have to consider some adaptations to make it play nice with the legacy of Project Explorer. So the implementation for the view part is simply to add a checkbox in the menu allowing to choose a top level element, to show whether there's an "Others" working set or not - when top-level elements are working set. It seems pretty consistent to me as users will see it immediately, and since the "Others" is not a working set (even totally the opposite), that we can add as a root element.
Let me put this another way. When using the Project Explorer and you create/import a new project and forget to put it in a Working Set when the top element is Working Sets, it never shows up and the user doesn't know why. And, yes, that happened to me early on and I was really confused. So, IMHO, showing Others in the Project Explorer should be the default like it is in the Package Explorer when top element is Working Sets. As long as that's true, I'm good. I don't really care about filtering. Others may. And I don't consider this a breaking change. It's fixing a bug (missing projects on creation).
(In reply to Doug Schaefer from comment #55) > So, IMHO, showing Others in the Project Explorer should be the default like > it is in the Package Explorer when top element is Working Sets. As long as > that's true, I'm good. Changing the default behavior (to show content that so far was explicitly filtered by user) is often a breaking change. I wouldn't mind personally, but that's usually the kind of things to negociate with Dani. As usual, a first iteration is to ship an opt-in solution (I proposed one and would be glad to see it reviewed ASAP so it gets chances to even get into Neon.2), and then to evaluate possibility to turn it opt-out in a 2nd iteration.
Gerrit change https://git.eclipse.org/r/81219 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=beb3471407acfef7cdadf19cde694eefedf1de80
Patch was merged and feature is now available from the "Top Level Elements > Show "others" working set" menu. Leaving it open to write a N&N entry.
New Gerrit change created: https://git.eclipse.org/r/82147
Gerrit change https://git.eclipse.org/r/82147 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=3b9dafd7c5b307e6b034b0ff26a71b8749b8e0f7
N&N done,
I tried with N20161002-2000 and it does not seem to work. 1. I've set top level element to working sets EXPECTED: 'Other Projects' working set is visible, but instead only projects are shown. 2. OK, I see there is another option Show 'Other Projects' Working Set. Why do we have this? Who does not want this? 3. Enabled that option ==> nothing changed.
(In reply to Dani Megert from comment #62) > 1. I've set top level element to working sets > EXPECTED: 'Other Projects' working set is visible, but instead only > projects are shown. This is the current behaviour of working set with Project Explorer: even if top level-elements are working set, at least one must be selected in the "Select working set..." dialog to show working sets as root. I believe if we want to change this, it should be another bug. Or maybe the menu item should say "Selected working sets" ? > 2. OK, I see there is another option Show 'Other Projects' Working Set. > Why do we have this? Who does not want this? The menu allows to have this feature opt-in and to not change current bahvior by default. If you're OK to get rid of the menu and show 'Other projects' by default, I'm all for it. > 3. Enabled that option > ==> nothing changed. Same as 1., as long as no working set is selected, it doesn't change anything.
(In reply to Mickael Istria from comment #63) > (In reply to Dani Megert from comment #62) > > 1. I've set top level element to working sets > > EXPECTED: 'Other Projects' working set is visible, but instead only > > projects are shown. > > This is the current behaviour of working set with Project Explorer: even if > top level-elements are working set, at least one must be selected in the > "Select working set..." dialog to show working sets as root. Even after checking the additional option, the 'Other Projects' working set did not appear in that dialog. So, no way to make it appear. > > 2. OK, I see there is another option Show 'Other Projects' Working Set. > > Why do we have this? Who does not want this? > > The menu allows to have this feature opt-in and to not change current > bahvior by default. If you're OK to get rid of the menu and show 'Other > projects' by default, I'm all for it. +1
Thanks for your feedback Dani, I see what are your expectations and I agree with it. I'm also glad that we can get rid of this menu and always have "Other projects".
+1 Thanks! Just to confirm, implementation details aside, the expectation is for it to work just as it does in the Package Explorer, pretty much exactly. If it's good enough for Java developers, it's good enough for everyone else too :).
New Gerrit change created: https://git.eclipse.org/r/82382
(In reply to Eclipse Genie from comment #67) > New Gerrit change created: https://git.eclipse.org/r/82382 This makes the Others working set appear, but in the 'Select Working Set...' dialog, the Others working set is not available. Even worse: it looks like the 'Configure Working Sets' functionality is completely missing (filed bug 503464).
(In reply to Dani Megert from comment #68) > This makes the Others working set appear, but in the 'Select Working Set...' > dialog, the Others working set is not available. Ok, I'll try to add it. However, the "Others" working set is exactly a non-working set, so we need to be careful about treating it as such. > Even worse: it looks like the 'Configure Working Sets' functionality is > completely missing (filed bug 503464). The "Select Working Set..." serves this purpose. What do you think is a missing blocker compared to the "Configure Working Set" dialog?
(In reply to Mickael Istria from comment #69) > (In reply to Dani Megert from comment #68) > > This makes the Others working set appear, but in the 'Select Working Set...' > > dialog, the Others working set is not available. > > Ok, I'll try to add it. However, the "Others" working set is exactly a > non-working set, so we need to be careful about treating it as such. Right, but if you then go back to Projects mode, the the ones from 'Others' are hidden. Another bug. > > Even worse: it looks like the 'Configure Working Sets' functionality is > > completely missing (filed bug 503464). > > The "Select Working Set..." serves this purpose. What do you think is a > missing blocker compared to the "Configure Working Set" dialog? Just compare the two dialogs. Doug already said it in comment 66: "the expectation is for it to work just as it does in the Package Explorer, pretty much exactly".
So you're ok to abandon all the concept of working set filtering in Project Explorer? As mentioned in previous comments, working sets are also used as filters in Project Explorer. We cannot expect things to work exactly the same than in Package Explorer without getting rid of this filtering capability.
(In reply to Mickael Istria from comment #71) > So you're ok to abandon all the concept of working set filtering in Project > Explorer? Mh, no. I did not say that. As mentioned in previous comments, working sets are also used as > filters in Project Explorer. We cannot expect things to work exactly the > same than in Package Explorer without getting rid of this filtering > capability. Not sure what "filtering" you are talking about, but the Package Explorer allows to filter on working sets in both modes. Please take a closer look at the Package Explorer.
The current implementation in M3 provides the bases of this feature but need some more work as reported by Danu. Splipping to M4. Should we put a note in the N&N to explicit that the UI/UX is not final and going to change by next milestone?
The overhaul should get rid of the option to enable/disable 'Other Projects'.
(In reply to Dani Megert from comment #74) > The overhaul should get rid of the option to enable/disable 'Other Projects'. Ok, I like the idea of removing options ;)
(In reply to Dani Megert from comment #74) > The overhaul should get rid of the option to enable/disable 'Other Projects'. I have a few additional questions: 1. When top-level elements=Working Sets, should the 'other projects' be always visible or only when there's content to show (ie projects not assigned to any enabled working set) 2. Should the "other projects" group/pseudo-working-set be also visible when top-level elements=Projects? Currently, projects in non-enabled working set are simply hidden; the alternative would be to group them under "other projects" anyway. In case all projects are shown, the "other projects" group would be hidden.
(In reply to Mickael Istria from comment #76) > (In reply to Dani Megert from comment #74) > > The overhaul should get rid of the option to enable/disable 'Other Projects'. > > I have a few additional questions: > 1. When top-level elements=Working Sets, should the 'other projects' be > always visible or only when there's content to show (ie projects not > assigned to any enabled working set) > 2. Should the "other projects" group/pseudo-working-set be also visible when > top-level elements=Projects? Currently, projects in non-enabled working set > are simply hidden; the alternative would be to group them under "other > projects" anyway. In case all projects are shown, the "other projects" group > would be hidden. 3. When top-level elements=Working Sets and no working set is selected, should we show the "Other projects" working set containing all projects, or show directly all projects?
New Gerrit change created: https://git.eclipse.org/r/89149
Mass move. Please move to a concrete milestone if you plan to work on this item.
@Dani: at the moment, the proposed fix is purely about UI. Moving to the same approach as JDT would require to create an actual working set object in the workspace and to compute it's content dynamically whenever something change regarding working sets. This is code that's on the workbench side, not on the navigator side any more. Is this fine? I'd like to merge an iteration on this topic with https://git.eclipse.org/r/89149 (which covers comment 74) before considering more complex implementations. Would that be fine?
(In reply to Mickael Istria from comment #80) > @Dani: at the moment, the proposed fix is purely about UI. Moving to the > same approach as JDT would require to create an actual working set object in > the workspace and to compute it's content dynamically whenever something > change regarding working sets. This is code that's on the workbench side, > not on the navigator side any more. > Is this fine? > > I'd like to merge an iteration on this topic with > https://git.eclipse.org/r/89149 (which covers comment 74) before considering > more complex implementations. Would that be fine? Nothing against such an improvement. But not enough to close this bug ;-).
In Oxygen, we still see the checkbox in the "Top-Level Elements" view menu. I think it's easier to track progress and future on this topic by marking this bug as fixed -as the feature is delivered- and opening new ones with finer grain.
This is still not working. I can provide steps but it's really simple to see that this is neither finished nor polished. Also, if you claim something like this: " I think it's easier to track progress and future on this topic by marking this bug as fixed " the only acceptable behavior is to open bug reports for all the missing parts that already got reported, so that they do not get lost.
This should really get polished during 4.8 or even for 4.7.1.
Gerrit change https://git.eclipse.org/r/89149 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=27f5324f7012bfe898448bed05df900e3acd7dbc
(In reply to Eclipse Genie from comment #85) > Gerrit change https://git.eclipse.org/r/89149 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=27f5324f7012bfe898448bed05df900e3acd7dbc > Is that supposed to fix the remaining issues?
(In reply to Dani Megert from comment #86) > Is that supposed to fix the remaining issues? Not all. It's an iteration that covers you comment #74 (remove the option) but it doesn't bring the "Others" working set in the working set selection dialog yet.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
