Summary: | [Workbench] Workbench should support non-adaptable objects | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | John Ruud <john.ruud> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | enhancement | ||
Priority: | P4 | CC: | Tod_Creasey |
Version: | 2.0 | Keywords: | investigate |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
John Ruud
2002-07-24 04:16:17 EDT
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 |