Community
Participate
Working Groups
Currently the labelProvider is specified as part of the navigatorContent extension point. There is no formal way to define only a label provider (that would then override an existing label provider). Should the label provider be made a first class extension, and what kind of semantics would be useful for the override capability? If there are no use cases identified for overriding label providers, then it will remain as is. This would likely be an M5 item.
I don't know of any use cases for overriding the label provider, but there may be some from the older Rational generic navigator, as it allowed content provider and label provider to be specified separately. I like the simplicity of the current approach, but would like to avoid having to match against the <expression> element for the label provider to be applied. I would expect any elements provided by the content provider of a navigator extension to use that extension's label provider, regardless of <enablement>.
It is interesting to note that, as Nick stated in bug 114940, it is actually the parent content provider that determines what the label of an item should be. As an example, consider a Java package in the Packages Explorer. In Flat mode when the package is a direct child of the source folder, the label should be the full package name. But, in heirarchy mode, when the parent is another package, the label is just the last package segment.
After some more playing around, I can see two cases here. - The first is what has been described by Nick in comment 1 (i.e. the parent content provider determines the labels for it's children). This is definitly required in some cases. - However, in some cases (probably most cases?), the parent is happy to allow the registered label provider provide the label and image. I have hit the second case in my prototyping for the team operations. The Team framework throws one or more model providers into a view but is happy to let the extensions for those providers provide a label and image. I think having a separate extension point for label provides helps here since the content provider can then choose whether to provide it's own label provider or use the one from the separate extension.
Without a specific use case that cannot be supported in some other way, I am closing this bugzilla as WONTFIX. The last case mentioned can be supported by a label provider that chooses to return null for items that it contributes to allow other extensions to jump in and provide a label. In general though, most clients I am aware of have a tight coupling between the label provider and content provider. JDT is particular tight on this point as the label provider requires the content provider in some cases to determine the correct label.
