Community
Participate
Working Groups
Created attachment 269391 [details] Suggestion on the dialog It would be very useful if the "Select Working Set" dialog had another option which would "select" all Working Sets that currently contain open projects, since the other ones are currently irrelevant. I suggest the option label to be "Working Sets with Open Projects"
Instead of adding another option to the "Select working set" dialog I added a filter to hide working sets, that are either empty or contain only closed projects.
Created attachment 270057 [details] Open projects working set filter in action
How does the proposed patch interact with the "Other Projects" working set (Bug 266030) ? Do the projects that are filtered out because they're in a working set with only closed project end up being shown in Other Projects? And if one opens a project from this "Other Projects" working set, would that automatically re-enable the actual working set and show the project back into it? I'm afraid this could be quite complicated to grok for most users.
(In reply to Mickael Istria from comment #3) > How does the proposed patch interact with the "Other Projects" working set > (Bug 266030) ? > Do the projects that are filtered out because they're in a working set with > only closed project end up being shown in Other Projects? And if one opens a > project from this "Other Projects" working set, would that automatically > re-enable the actual working set and show the project back into it? > I'm afraid this could be quite complicated to grok for most users. This new filter doesn't interfere with the "Other Projects" working set. Working sets with only closed projects are just filtered, i.e. hidden from the UI, but the internal mapping to the working set will stay, so I doesn't appear in the "Other projects" working set. Thanks to your comment I realized that the Filter option isn't part of the Package Explorer Filters. I will add that in a separate patch for jdt.ui
(In reply to Conrad Groth from comment #4) > This new filter doesn't interfere with the "Other Projects" working set. > Working sets with only closed projects are just filtered, i.e. hidden from > the UI, but the internal mapping to the working set will stay, so I doesn't > appear in the "Other projects" working set. I believe this might be a problem: when a user has the "Other projects" visible, they most likely expect *all* other projects that are not shown somewhere else to be visible there. I think it's important that if Other Projects ws is shown, all other projects, including the closed ones when your filter is enabled, get to the "Other projects"
(In reply to Mickael Istria from comment #5) > I believe this might be a problem: when a user has the "Other projects" > visible, they most likely expect *all* other projects that are not shown > somewhere else to be visible there. I think it's important that if Other > Projects ws is shown, all other projects, including the closed ones when > your filter is enabled, get to the "Other projects" I don't unterstand the use-case of your comment. So let me describe my use-case which caused me to file this bug (Silvio is a team colleague) and to provide a patch: I'm working with hundreds of projects, sorted into 60 working sets. Our eclipse IDE is provided by OOMPH and the OOMPH installer creates these 60 working sets. When I'm working on one component, I only need projects from two or three working sets. To reduce build times I only open the projects from these working sets and close all the others. To keep my package explorer clear I use the existing "Closed projects" filter to hide all closed projects from the view. By the way, projects that are hidden because of the "Closed projects" filter don't appear in the "Other projects" working set. Additionally closed projects in the "Other projects" working set are also hidden (as expected). Unfortunately all the 60 working sets still appear in the package explorer, although most of them don't contain open projects. So my proposed filter is just a continuation of the "Closed projects" filter for (needless) working sets. I know that there's the "Select working set" option. Right now I'm using this option, but I have to do it manually. So why not creating an filter, that does that automatically?
(In reply to Conrad Groth from comment #6) > (In reply to Mickael Istria from comment #5) > > I believe this might be a problem: when a user has the "Other projects" > > visible, they most likely expect *all* other projects that are not shown > > somewhere else to be visible there. If user selects a filter to hide "some kind of" projects, why should they be moved to "Other"? > > I think it's important that if Other > > Projects ws is shown, all other projects, including the closed ones when > > your filter is enabled, get to the "Other projects" I don't think so. I think it is clear that the projects should not move from one to another working set just because they are closed or not. "Other projects" is just the place for not yet categorized projects. It is definitely not the place for "closed" projects, and I think users can get it too. > I'm working with hundreds of projects, sorted into 60 working sets. Our > eclipse IDE is provided by OOMPH and the OOMPH installer creates these 60 > working sets. When I'm working on one component, I only need projects from > two or three working sets. To reduce build times I only open the projects > from these working sets and close all the others. To keep my package > explorer clear I use the existing "Closed projects" filter to hide all > closed projects from the view. By the way, projects that are hidden because > of the "Closed projects" filter don't appear in the "Other projects" working > set. Additionally closed projects in the "Other projects" working set are > also hidden (as expected). Unfortunately all the 60 working sets still > appear in the package explorer, although most of them don't contain open > projects. So my proposed filter is just a continuation of the "Closed > projects" filter for (needless) working sets. This describes nicely my own (or our lab) use case. +1 for implementing proposal. I have only small proposals for changing the text of the filter, I will reply on the patch. Moving to M3 because M2 code freeze is tomorrow.
Just to make sure: with your filter and Other Projects are enabled, would all the closed project from an automatically hidden working set be shown under "Other Projects"? I think it's important to get this behavior, as it's the typicak expectation of "Other projects". See for example how it behaves when you manually unselect (somehow equivalent to filtering out) a working set: the project under it go to "Other projects". As per your use-case, it seems to be a typical use-cases for "Select Working Sets": when switching to the new task, you go to select working sets, unselect all except the one you want; and it should be good to run. If you want to close all other projects, I think it would be a different patch and layer to add this feature. Typically, you may simply want a "Close included projects" operation on working sets (including "Other Projects") that would work for you the other way round, manipulating working sets to control included projects, and not project state to control working set visibility. Depending on the layout of your projects, I would also encourage you to check "Project Explorer"'s nested project layout to evaluate whether it can fit for you: https://www.eclipse.org/mars/noteworthy/#_nested_hierarchical_view_of_projects . I know several users have simply stopped using working sets since this got introduced. You could be a lucky one too ;) Removing the 4.8.M2 target as code-freeze is tomorrow and this change is still not consensual enough to be considered for a merge.
(In reply to Andrey Loskutov from comment #7) > (In reply to Conrad Groth from comment #6) > > (In reply to Mickael Istria from comment #5) > > > I believe this might be a problem: when a user has the "Other projects" > > > visible, they most likely expect *all* other projects that are not shown > > > somewhere else to be visible there. > > If user selects a filter to hide "some kind of" projects, why should they be > moved to "Other"? > [...] > I don't think so. I think it is clear that the projects should not move from > one to another working set just because they are closed or not. "Other > projects" is just the place for not yet categorized projects. It is > definitely not the place for "closed" projects, and I think users can get it > too. See current behavior of "Other projects" in both Package Explorer from JDT and Project Explorer from Platform. It shows every project that's not shown someplace else. Breaking this behavior would introduce inconsistency and confusion. Working Sets already do enough on that topic ;) > This describes nicely my own (or our lab) use case. +1 for implementing > proposal. I have only small proposals for changing the text of the filter, I > will reply on the patch. See comment above. I believe a "close all projects" action on working set would help a lot for such use-case without introducing new rules in how projects are shown or not.
(In reply to Mickael Istria from comment #8) > Just to make sure: with your filter and Other Projects are enabled, would > all the closed project from an automatically hidden working set be shown > under "Other Projects"? No, they would be just hidden. > I think it's important to get this behavior, as it's the typicak expectation > of "Other projects". See for example how it behaves when you manually > unselect (somehow equivalent to filtering out) a working set: the project > under it go to "Other projects". No, the purpose of the proposed filter is to reduce visual garbage. If we have ~200 projects, 50 working sets and have only 3 opened projects, we don't want to see *ANY* of closed projects and working sets including them. It makes no sense to move 197 closed projects from 49 working sets to "Other" working set just because they are closed. But let assume we will really move those 197 closed projects to the "Other" working sets. Now user opens one from those closed projects, and ... it disappears (to appear somewhere else)! This would drive users crazy! > As per your use-case, it seems to be a typical use-cases for "Select Working > Sets": when switching to the new task, you go to select working sets, > unselect all except the one you want; and it should be good to run. I always found this "descent" into the working set highly discouraging. Also it only allows to go into a single working set, but typically we have multiple opened projects in multiple working sets. We just won't see *others*. > Depending on the layout of your projects, I would also encourage you to > check "Project Explorer"'s nested project layout to evaluate whether it can > fit for you: This does not fit for us - we do not have hierarchies.
(In reply to Andrey Loskutov from comment #10) > But let assume we will really move those 197 closed projects to the "Other" > working sets. Now user opens one from those closed projects, and ... it > disappears (to appear somewhere else)! This would drive users crazy! Ok, and now let's assume a user has some working set and "Other Projects" enabled and is use to seeing the projects that are not part of any working set in "Other Projects". Suddenly, they close the last open project of a working set, the working set suddenly disappear and none of the included projects is in "Other Projects", so they seem lost. I think some users would get crazy too as they wouldn't understand the expectation behing "Open Projects". This story of automatically filtering out is not clean by essence, I see no state that would confuse the other. But, I may have a good trade-off: instead of a new filter, we go for a toggle action in the Project Explorer called "Automatically disable working sets with no open projects", which would do just what the title say. So you get the working sets disappearing when getting empty, without changing any logic in Other Projects and whatever, so if you don't want to see "Other Projects" you don't enable it, and working sets would just vanish automatically and would remain controllable through the usual UI and workflows.
(In reply to Mickael Istria from comment #8) > Depending on the layout of your projects, I would also encourage you to > check "Project Explorer"'s nested project layout to evaluate whether it can > fit for you: > https://www.eclipse.org/mars/noteworthy/ > #_nested_hierarchical_view_of_projects . I know several users have simply > stopped using working sets since this got introduced. You could be a lucky > one too ;) Our hierarchies are not always aligned to the working sets. I tried to use that feature but wasn't happy with it.
(In reply to Mickael Istria from comment #11) > Ok, and now let's assume a user has some working set and "Other Projects" > enabled and is use to seeing the projects that are not part of any working > set in "Other Projects". Suddenly, they close the last open project of a > working set, the working set suddenly disappear and none of the included > projects is in "Other Projects", so they seem lost. I think some users would > get crazy too as they wouldn't understand the expectation behing "Open > Projects". > This story of automatically filtering out is not clean by essence, I see no > state that would confuse the other. If I use the provided filters, e.g. the existing "closed projects" filter, then I close a project and it disappears from the UI, that's exactly what I expect from such filters. > But, I may have a good trade-off: instead of a new filter, we go for a > toggle action in the Project Explorer called "Automatically disable working > sets with no open projects", which would do just what the title say. So you > get the working sets disappearing when getting empty, without changing any > logic in Other Projects and whatever, so if you don't want to see "Other > Projects" you don't enable it, and working sets would just vanish > automatically and would remain controllable through the usual UI and > workflows. I don't like this solution from an UX point of view. Such a toggle action would appear at a prominent point and is not useful for all the people out there not using working sets at all. The proposed filter will be in the list of possible filters until one uses it. Then it appears in the sub menu for the recently used filters. So whoever uses it, sees it directly in the menu, all the others are not disturbed. On the other hand there's an existing API to filter the projects tree. Why should we not use it?
(In reply to Conrad Groth from comment #13) > If I use the provided filters, e.g. the existing "closed projects" filter, > then I close a project and it disappears from the UI, that's exactly what I > expect from such filters. Ok, I have to admit I don't use it, so I never complained. But I don't think it's a clean and consistent behavior combined with working sets... > Such a toggle action > would appear at a prominent point and is not useful for all the people out > there not using working sets at all. Ok, I agree. So what about having this option in the "Select working sets" dialog when users actually manage their working sets? > Why should we not use it? I can repeat it again: the proposed behavior is IMHO plainly confusing and I'd rather spend time investigating alternatives before introducing in Platform UI a feature whose behavior can easily be perceived as a bug by some users.
It's not OK to mix the working set concept with the filters. A better approach is to put this information into the working set selection dialog. Maybe instead of the initially proposed new working set, one could specify to hide working sets with no open projects.
(In reply to Dani Megert from comment #15) > It's not OK to mix the working set concept with the filters. Can you explain why? Am I missing some important information about working sets, because for me working sets are just a method to (logically) group projects similar to the hierarchical view when you have (source code) folders to group your projects physically. > A better approach is to put this information into the working set selection > dialog. > > Maybe instead of the initially proposed new working set, one could specify > to hide working sets with no open projects. Can you explain your proposals, in which menu or windows do you want to have these options and in which form (push/radio/toggle button)?
Created attachment 270238 [details] UI alternatives to hide empty working sets
I added a UI mock up to sum up the different alternatives we are talking about. Did I forget an alternative? From my point of view I still prefer the alternative 1.
(In reply to Dani Megert from comment #15) > It's not OK to mix the working set concept with the filters. I tested the "Name filter patterns" (from the Package Explorer Filters menu item) with a name of an existing working set and it got hidden. So the existing filter concept already affects working sets. That's either a bug or we agree that the filter concept can also affect working sets.
(In reply to Conrad Groth from comment #18) > I added a UI mock up to sum up the different alternatives we are talking > about. Did I forget an alternative? > From my point of view I still prefer the alternative 1. Yep, me too.
lternative 3 is IMO the best one: * One configure ws behavior in a single place, there is no need to manipulate filters and both concepts remain separated. * it's not too intrusive for the average user who would most likely not use this option (as opposed to the view configuration menu) Technically, I don't think this should be implemented as a filter but as a preference/memento on the view to customize the behaviour of workingset content provider.
(In reply to Dani Megert from comment #15) > It's not OK to mix the working set concept with the filters. Can you explain why? I had a look into affected classes for alternative 3 and they will become even messier as they are now. So I'm really thinking about whether I should try to implement alternative 3 at all. Another point to think about: The package explorer allows to hide working sets (right click on a working set -> Delete -> Hide). How should that work together with the suggested filter?
(In reply to Conrad Groth from comment #22) > (In reply to Dani Megert from comment #15) > > It's not OK to mix the working set concept with the filters. > Can you explain why? Because they are different concepts and the user option to hide working sets with no open projects should be where working sets are configured. One general comment for the feature: hiding a working set removes the ability to create a project directly in that working set by first selecting the working set in the Package or Project Explorer. It also removes to feature to move projects from one working set to another (empty and hence hidden) working set.
This bug did not get delivered for the specified target milestone. Please set the target milestone when you plan to deliver the fix.
