Community
Participate
Working Groups
In my workspace are several versions of the same project, like different releases which have to be maintened. Each version is a separate project in the eclipse manner, although the resources are nearly the same. To switch really fast between the different versions (projects), I have defined a workingset for each project, containing exactly one project. It would be nice, when the workingsets are switched, editors which contain files not in the current working sets are closed or even better not visible. Further more, the JDT 'Open Type' menu should take respect for the workingsets too, e.g. classes which are not in the current workingset should not be displayed.
Note that working sets are view specific. They are not global to the workspace. Open Type is a workspace action so it should not filter the type list based on a working set. For the same reason I don't think it would be correct to close editors whena view switches working sets. The editors may not have been opened by that view. Go to Type/Resource on the other hand are view specific so it would be reasonable to filter the dialog based on the working set selected in the target view (Package Explorer, Resource Navigator). Bug 26206 tracks this for the Navigator. Are you essentially asking for a global working set to replace view working sets? This could be either set on the workspace ("very global"), window or perspective ("least global").
I am a little bit confused about the fact that the working sets are view specific, because package explorer view and navigator view share the same working sets, and I even can narrow all searches to a specific working set etc. In my opinion it would be natural and consistent to allow this filtering to a working set in the Open Type workspace action too. I agree that the open editors should not be closed by a working set change, but it is possible to simply not show them ?
View specific means a working set is selected for one view vs. all views in the workbench window. You can have a different working set for every view that supports them. A workspace global working set would automatically be set on all views (this we don't support at this time). When you say the open type dialog should honor the current working set I'm not sure what working set you are refering to. Are you suggesting the open type dialog (and open resource dialog) should allow setting a working set *just for the dialog*? That would actually make sense and it would be similar to the search working sets as you suggest. Likewise for editors, it would be possible to allow selecting a working set for editors to switch between editor sets. I believe Jared's editor view (http://sourceforge.net/projects/editorlist/) supports this and there was talk about supporting this in the redesigned editor management (which was not shipped for 2.1).
The editor list plugin is also available using the built-in Eclipse update mechanism using http://editorlist.sourceforge.net/site
I took a quick look at the editorlist plugin, but in my opinion it manages an own concept of working sets. If it is possible, i would like ;-) that the working set filters are implemented on Open type and the editors and it should be possible to 'link' the actual working set to this filter without the need to activate the filter like it is current implemented in the search dialog.
Like I said, there is no notion of a active or global working set since each view may have its own. That's why you have to set the same working set in the Navigator and in the Package Explorer separately. I think you are asking for one "global" working set to be used by views, editors and dialogs. This is essentially the request in bug 22328 although not elaborated as detailed.
Can I mark this as a duplicate of bug 22328?
*** This bug has been marked as a duplicate of 22328 ***
