Community
Participate
Working Groups
The outline and property views work well for navigating adaptable objects, but it is not always possible to require that objects implement IAdaptable, for example if classes are part of 3rd-party libraries. While it is possible to work around the problem by subclassing and cloning various workbench classes, it seems like a better solution would be to simply let the platform's adapter manager return the appropriate adapter if everything else fails (i.e. if the object is not an adaptable). For example, WorkbenchLabelProvider.getAdapter (Object) could change from: protected final IWorkbenchAdapter getAdapter(Object o) { if (!(o instanceof IAdaptable)) { return null; } return (IWorkbenchAdapter)((IAdaptable)o).getAdapter (IWorkbenchAdapter.class); } to: protected IWorkbenchAdapter getAdapter(Object o) { if (o instanceof IAdaptable) return (IWorkbenchAdapter)((IAdaptable)o).getAdapter (IWorkbenchAdapter.class); else return (IWorkbenchAdapter)Platform.getAdapterManager ().getAdapter(o, IWorkbenchAdapter.class); } Similar changes could be made to WorkbenchContentProvider.getAdapter(Object) and PropertySourceEntry.getPropertySource(Object)
Note that a property sheet page can be configured with a IPropertySourceProvider for this purpose.
Yes, implementing my own IPropertySourceProvider was one of the workarounds I made. Others included subclassing WorkbenchContentProvider.getAdapter(Object), CLONING WorkbenchLabelProvider because its getAdapter method is defined as “final”, and setting up the various workbench objects to use these objects. All this wouldn’t be necessary if all the workbench classes were to use the platform’s adapter manager as a last resort
There should not be no need for cloning the WorkbenchLabelProvider as described in comment #3 if getWorkbenchAdapter and getWorkbenchAdapter2 methods weren't declared as final. In my case removing the final from those two methods would suffice, but I don't see any reason to lock down all other method implementations in that class either... Except only if it would increase performance somehow, but even then it's rather shortsighted and overzelaus optimization imho. As I see it, this bug has 2 fix paths - I can provide patches for both of them, if necessary: a) make getWorkspaceAdapter methods non-final, opening up them to all kinds of interesting implementations, I dare not even imagine. b) implement getWorkspaceAdapterMethods so that they would try retrieving adapters even if provided objects are not adaptable. adn PLEASE ... fix it asap... this is not such a big code change per se, but the benefits are HUGE!
There are currently no plans to work on this feature
