RE: [platform-ui-dev] Working sets on a workbench window

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Mik Kersten wrote on 29/09/2005 01:39:56 PM:

> Thinking longer-term, it would be great if improvements
in working 
> sets could deprecate most needs for multiple workspaces and the need
> for a “Switch Workspace” UI.  You've probably considered this,
but I
> wonder if there is potential for a more radical approach where 
> understanding of working sets get pushed down to the resource level.
> So when you select your global working set, the workspace itself 
> filters things that aren't part of it.  If you ask IWorkspaceRoot
> for all the projects, you only get the ones in the working set, only
> get notified of resource deltas for resources in the working set,
> etc.  This could address Martin's concern about the many non-SDK
> views that aren't aware of working sets.   It could also get
rid of 
> things like the need for "Build Working Set" since the current
> working set (or entire workspace) would always be built, and could
> make runtime configurations use the global working set transparently
> when "Workspace Plug-ins" is enabled.  Might be too
radical, but it 
> seems that the more the user can depend on a single mechanism for
> toggling the active working set the better.

We indeed already have an enhancement request for
this:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=84988

However, resource-level filtering is very different
from UI filtering, and there are cases where you want to filter the UI
but still want the entire workspace available programmatically.  For
example, you may still want the compiler to be able to access files in
other projects outside your working set, even if you want those other projects
to be hidden from view in the UI.  And of course, working sets are
not tied to IResource; there are other kinds of domain objects in the UI
that working sets operate on, so pushing concepts to the workspace level
don't help these cases either.