Community
Participate
Working Groups
See Working Sets RFC for information.
Eduardo is making a few minor changes to proposal. What this boils down to is: - push down the current working set APIs from Search to UI (they're pretty minimal) - generalize it to be a collection of IAdaptable instead of IResource -> use IPersistable and IElementFactory to persist the elements in the working set - change our views (mainly Navigator and Tasks) to allow a working set to be chosen as a filter -> the Navigator should work much like the Packages view does currently -> they will only understand working sets of IResources (or IAdaptables which can provide an IResource) - Search currently has a viewer filter which filters by a working set of resources -> this is currently used by the packages view -> we should push this down too and use it where appropriate -> it's just a convenience, though, not an essential part of the working set API, and may not be the optimal way of showing a working set - add get/setWorkingSet to IWorkbenchPage to replace the concept of page input -> deprecate get/setInput on IWorkbenchPage - change views to seed themselves with the page's working set rather than the page's input -> views should check first for a working set, then using the input if there is no working set Search and JDT will also have to be changed accordingly, so this needs to be done by M4 or early M5. Since we're halfway through the cycle for M4 already, early M5 is probably the best we can do.
From NE, Actually, Kevin has convinced me that it would be simpler if working sets were specified only on the page, and not on a per-view basis. This means we need to: -- provide UI to allow the working set for a page to be changed (in addition to providing its initial working set). -- allow interested views to be notified of the change (add support for property change listeners to IWorkbenchPage) -- we don't need per-view UI for specifying the working set
New work item based on discussion between Nick Edgar and Erich Gamma: -introduce extension point to allow other plugins to contribute a working set editing dialog. Workbench UI will provide a working set editing dialog that works with resources only (IResource) as well as a working set selection dialog that lists working sets. Also, the property change notification for working sets should likely reside in the working sets themselves (or in some working set registry). This would allow plugins to use working sets outside the IWorkbenchPage context. See also posting from Jared Burns on 3/20/02 in platform-ui-dev.
Tried out Eduardo's suggestion to implement a workbench adapter (WorkbenchWorkingSet) that wraps a working set. The WorkbenchWorkingSet was to be used by the WorkbenchContentProvider to dynamically filter out all non- working set resources. WorkbenchContentProvider#getChildren returned an array of WorkbenchWorkingSet objects. Each object forwarded adapter requests to the original, wrapped, resource. This seemed to work well and left the WorkbenchContentProvider largely unchanged. However, there seem to be a number of places where a strictly IResource based WorkbenchContentProvider/ResourceNavigator is assumed. Two involved the context menu population and another one the resource change notification. The resource change events for a deleted resource no longer had the correct delta type (IResourceDelta.REMOVED). It doesn't seem safe to go ahead with the wrapping approach since there could be any number of places that rely on IResource instead of using adapters. I may revert back to doing the working set filtering in the WorkbenchContentProvider or just use the default WorkingSetFilter.
The strange resource delta type was due to the fact that I deleted the .classpath file. I got CHANGED instead of REMOVED. So resource changes do work. However, extra code is required in the WorkbenchContentProvider so that the viewer is updated properly. The viewer has to be updated with the wrapped resource that is returned in getChildren. I also implemented working set change event notification as follows: A working set sends one property change event to registered listeners when the contents is changed. A different event is sent when the working set name is changed. IWorkingSet has API for adding and removing listeners. A new interface IWorkingSetRegistry has methods that used to be static in IWorkingSet to keep a list of working sets as well as API for adding and removing listeners. The default implementation sends a property change event when a working set is added and a different event when one is removed. It also listens to workspace resource changes and ensure that no working set contains a removed item.
Working set code has been released. It is in the M5 build as an optional "work in progress" feature that can be enabled in the Workbench preferences. It is enabled by default in post M5 builds. Note that IWorkingSetRegistry has been renamed to IWorkingSetManager. There is a new extension point, org.eclipse.ui.workingSets, for defining a custom UI for editing working sets. See the documentation for the extension point for details.
