Community
Participate
Working Groups
In the Java Browsing perspective I always have the same Working Set chosen for the Projects, Packages, and Types views. When I want to change the working set I'm using, I have to change each view separately. It is desirable to be able to link the working set selection for these views so they always are using the same working set as each other. This could be a specific setting just for these particular views, or it could be implemented as a more general feature as follows: A Perspective defines the "Perspective Working Set" which the user selects. Any Views that are open in that Perspective and that make use of a Working Set then have the option of using the Perspective Working Set or using their own.
Note that if it is decided the more general option is more desirable, this should be re-assigned to Platform-UI.
There are no plans to link views together since their basic intention is to work standalone so that users can define their own perspective. Moving to Platform UI to comment the more general request.
I think the working set should be tied accross all perspectives and even all workbench windows. For example, the Synchronize View also displays a working set, and I have *every* perpective open in its own window. So, I would want to change all views simultaneously, in all windows. Also, if views are sharing the working set, the UI should not be on each view, but on the window's toolbar. One way to allow this, *and* still allow the current behavior, is to add a new special working set setting called "Use Workspace Setting". Then, a widget on the toolbar would allow choosing the active workspace working set, which would affect any view with this as its setting.
I think this bugzilla addresses the scalability issue of eclipse. The UI requires too much micromanagement, especially in larger products with additional types of "Navigator" views.
This is a dup of bug 22328
*** This bug has been marked as a duplicate of 22328 ***
No, this is not really a duplicate. I don't agree that Bug 22328 is duplicate with this one. They are similar and somewhat related, yes, but 22328 seems to talking about a different issue. From one of the comments: > This seems to be asking to > 1) have an option to close projects that are not in a working set (and none of > their children are in a working set) > 2) support working sets in every view Neither of those things are what this request is for. this request is smaller in scope in that it only asks for the ability to link working set selection (possibly by defining a "global" working set that can be chosen by any view that supports working sets. I think the diffrences are important enough to warrant different work. Perhaps a dependency between the two requests would be better...
Lets reopen then.
I do believe that the case is better for having a working set setting that is linked between views i.e. a global/perspective working set, rather than having separate working set settings for each view. This global setting should be changeable from the Package Explorer. Right now, whenever I change the working set in the Package Explorer, I have to change the working set filter in both the Problems and Tasks views, which is somewhat inconvenient. I'm not willing to have separate workspaces, since I would then have to synchronise my workspace settings over all of those separate workspaces.
> I do believe that the case is better for having a working set setting that is > linked between views i.e. a global/perspective working set, rather than having > separate working set settings for each view. This global setting should be > changeable from the Package Explorer. You can't arbitrarily pick some view to define the "workbench" working set. What if that view isn't visible?
Well then, the flippant answer would probably be to say that making the Package Explorer view visible again only takes an extra step or two. But I do agree with you that making the Package Explorer view as the guardian would make the solution specific to only a certain class of users i.e. Java programmers. Some other possible solutions that I could think of: 1. Use a button with a drop-down menu or a combo box (like the font selection combo box in Word), on a toolbar. 2. Make it programmatically possible to be notified whenever the working set selection changes in the Package Explorer, and programmatically possible to change the filters in the Problems and Tasks views.
No special attention should be paid to Package Explorer (or any other view). (BTW, not all Java Programmer Eclipse users use Package Explorer - I never use it, choosing instead the Java Browsing perspective). As my initial request and Comment #3 say, there should be either a Perspective-wide or Workbench-wide working set, and then each view can be set to use either the Perspective Working Set, the Workbench Working Set, another working set (current functionality), or no working set at all (current functionality). In essense what this enhancement should be is one or two additional choices besides "No Working Set" and "A Particular Working Set", with those additional choices being "pointers" to a broader choice. Similar to how a Project can use the workspace settings for some things (eg, compiler options) or override them if need be. Now the real question is, when is this going to get some developer attention...?
The suggestion in comment 3 already covers what both of you have been saying.
Yep, the suggestion in comment 3 would be great.
Could this PR be considered for the 3.2 plan? Together with the new working set support in the Open Type dialog, the solution from comment 3 would provide a seamless working set support for people working with big workspaces.
I would love to do this for 3.2 - this is one of things that prevents me from using working sets more often.
With the exception of the linking specified by Randy in comment #3 the platform-ui portion of this bug has been addressed by bug 108149. I've opened bug 109143 to address that concern. *** This bug has been marked as a duplicate of 108149 ***
Kim, I think the correct resolution of this bug would be to move it to JDT UI to support the new APIs (or file a new bug requesting this) otherwise the linking will not work, right?
It happens there are components that need to roll with this other than JDT. Perhaps you could enter a fresh bug for your own component?
Kim, is it possible to create a new working set that offers the linked behavior for free to existing consumers of working sets?
It might be possible to have an aggregate working set of some kind...
