Community
Participate
Working Groups
Build ID: 3.3M6 I'm using the ShowInTarget() support to show the history of an IAdaptable object. (The actual type is a GEF edit part. (Implements IAdaptable) and in this case can adapt to IResource) CommonViewer uses various providers to get contributions for it. It uses the <possibleChildren> ext pt element to figure out which contributions to ask for parents of children. (In this case, ResourceExtensionContentProvider) Without supplying the evaluation targets for <adapt type="IResource" and type="IFile", the viewer will not be able to select an IFile for a StructuredSelection that contains an object that adapts to IResource. This is related to bug 182018
What is the plan for this in 3.4?
Hi Min, Can you help me understand the request/requirement to boil out of this? Are you requesting that a particular extension declare "adapts to IResource" in its possible children expression? Or a change in the core framework to support some new behavior?
If I have an EditPart (adapts to IResource) selected, and I tell ProjectNavigator to IShowInTarget#show() and pass it the selection that contains the edit part, I want it to reveal the associated IResource. Now, if I understand this right, this should work if ResourceExtensionContentProvider specified possibleChildren as "any thing that adapts to IResource."
So, there has been no activity on this defect for a while, so I'm going to clarify what my intentions where. This is really an Enhancement request, as ShowInTarget does work fine, but not exactly how I want. The problem stems from a weird architecture requirements due to unknown dependencies. The thing is that the "model item" can be represented one way in an editor, and a different way in the navigator. These two items are in fact the same "model item." The editor does not know specifically what item shows up in the navigator, and the navigator does not know what shows up in the editor. There should be some way to "morph" the actual item in the ShowInContext to "real item" and then go through the content contributions of the common navigator also looking for the tree item object that represents to the model item, but is in fact represented a different way. This also gets trickier as content providers usually create items lazily, so when this show in request is executed, the content providers might need to expand completely. Sems acceptable, since implementing "show in" would have to require this. Show in target currently does not expand content contributors. It really seems like it should do so, so that things that have never been expanded could also be revealed.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
