Community
Participate
Working Groups
I20061212-0010 The fixes for bug 166577 and bug 166682 should help ensuring that only applicable elements are added to a working set. Currently, this does not work since no contributor to 'org.eclipse.ui.workingSets' uses the 'applicableType' element (I can e.g. add a breakpoint to a resource working set). Furthermore, I'm not sure the 'applicableType' test is the best way to support this functionality. E.g. Java working sets currently behave weird if you add an IProject, but if the IProject adapts to IJavaProject, then the IJavaProject could safely be added. I think it would be better if the *adapted* object would be added to / removed from the working set, and not the original element. Bug 167595 is for similar functionality in the CVS checkout wizard.
Yeah, I've been thinking the same thing you have (which is why there isn't any use of the API in UI and I haven't advertised it at all). I was going to talk to you guys after the milestone about it.
instead of isApplicable() I was thinking of getApplicable() which returns an IAdaptable. If the object can be added to the set as is it's returned otherwise the applicable adaptable type is returned. If it's not applicable then null is returned.
An even more flexible solution would be a user-supplied class that controls what is added to (or removed from) a working set. It could have an interface like this, roughly: interface IWorkingSetModifier { /** * Converts the given elements for addition to /removal from the working set. * @return the (possibly adapted) elements to add to /remove from the ws */ IAdaptable[] getElements(IWorkingSet ws, IAdaptable[] elements); } The advantage would be that clients could also fold elements together or expand them at will.
I like the idea in principal but I'm hesitant to add another class to working sets that would need to navigate the lazy loading problem we have already with updaters. Perhaps workbench could provide a default implementation of this class that could be configured declaratively in the plugin.xml as to avoid this problem... I will investigate
I've added the following method to IWorkingSet after scrapping isApplicable: /** * Transforms the supplied elements into elements that are suitable for * containment in this working set. This is useful for UI elements which * wish to filter contributions to working sets based on applicability. This * is a hint, however, and is not considered when the * {@link #setElements(IAdaptable[])} method is invoked. * * @param objects * the objects to transform * @return an array of transformed elements that be empty if no elements * from the original array are suitable * @since 3.3 */ public IAdaptable[] adaptElements(IAdaptable[] objects); } This will defer to an IWorkingSetElementAdapter interface (declared in the working set schema) method : /** * Converts the given elements for addition to /removal from the working * set. * * @return the (possibly adapted) elements to add to /remove from the * working set */ IAdaptable[] adaptElements(IWorkingSet ws, IAdaptable[] elements); A default implementation of this interface has been provided in BasicWorkingSetElementAdapter. This class implements IExecutableExtension and can be provided customization arguments in the form: <workingSet elementAdapterClass="org.eclipse.ui.BasicWorkingSetElementAdapter:class1.to.adapt.to[;option1=value1][;option2=value2],class2.to.adapt.to[;option1=value1][;option2=value2][,...]" .../> This implementation will inspect supplied IAdaptables and try and match them to the classes supplied after the ":". If a direct assignemnt can be made the elements are returned as is otherwise the adapter manager is consulted. If the manager does not yeild results the getAdapter() method will be tried if and only if the class specified is already loaded by the system. I will follow up with a mailing list posting/blog posting sometime this week.
I think the Javadoc of org.eclipse.ui.IWorkingSet should be updated a bit: - setElements(IAdaptable[]) should recommend setting only elements that have been funnelled through #adaptElements(IAdaptable[]) - adaptElements(IAdaptable[]) should contain @see org.eclipse.ui.IWorkingSetElementAdapter @see org.eclipse.ui.BasicWorkingSetElementAdapter
Comments have been added to HEAD. Have you guys had a chance to examine this API with respect to the Java working set?
> Have you guys had a chance to examine this API with respect to the Java working > set? Yes, the Java working set contribution has been updated just before Christmas, and it works nice with the AddTo / RemoveFrom toolbar buttons. The fix for bug 167595 uses the mechanism in the CVS checkout wizard. It just tries to add the project to the selected working set. This works fine if the working set accepts the project. Unfortunately, the project is not yet available at the time the user selects a working set, so we have no way to prevent the user from selecting a working set that won't accept the project. But IMO, the current solution is good enough. Note: There are 2 more working set types in the Eclipse SDK (breakpoints and plug-in) which don't have an elementAdapterClass so far. Could you please inform them? Maybe you should also add an entry to the 3.3 migration guide (org.eclipse.platform.doc.isv/porting/3.3/recommended.html).
Verified in I20070206-0010
