Community
Participate
Working Groups
M1 Consider the following decorator markup <extension point="org.eclipse.ui.decorators"> <decorator adaptable="true" icon="icons/binary_co.gif" id="ContentTypeTest.decorator2" label="ContentTypeTest.decorator2" location="TOP_LEFT"> <enablement> <and> <objectClass name="org.eclipse.core.resources.IProject"/> <pluginState id="org.eclipse.jdt.debug.ui" value="activated"/> </and> </enablement> </decorator> </extension> This will not update in the ResourceNavigator because the resourceChanged events are not being fired when this property changes. See Bug 106395 for more background
I don't think bug 106395 was the bug you wanted to reference.
I think handling the label decorator triggering in the workbench content provider is the wrong think to do since only a handfull views in Eclipse are using this provider. Doing so will force all other views to do the same which will never happen (for example CVS and package explorer will not profit from this). I think the problem should be solved in the following way: The declarative label decorator manager should trigger the label updates. It knows about the enablement sections of the delcared label decorators. For example if now plug-in state decorator is registered there is no need to listen to bundle changes. I know that such an implementation isn't easy but it is IMO the only way to solve this issue in a general way.
The declarative decorator case is interesting. For the CVS decorator, we assume that it is our reponsibility to issue label changes when state that affects the decorator changes. If you apply this same logic to a declaritive decorator, it definitly would indicate that the declarative decorator (or the decorator manager) is reponsible for issuing the label changes. The problem is that the decorator is enabled/disabled using an enablement rule that has no knowledge that it is being used to determine a decorator state. It seems like the enablement rules themselves need a state change notification mechanism so that the declarative decorator will know when it needs to fire label changes.
The issue is two fold with doing that 1) redundant events. Anyone who listens to resources for any reasons and sends an update will now get two updates 2) Label providers do not start the process - they are objects that get requests from other objects to get images and text. Hooking up the label provider to listen to workbench events is inconsistent. If we were to add this sort of listening anywhere outside of a content provider it would be the decorator manager - the issue there is performance however. I am concerned about the amount of redundant events that would generate if the views are taken out of the equation. As to your point about declarative decorators I think this is a general issue for all decorators as they have this enablement issue too - I think it is too much work for a decorator implementor to hook this up as well.
Should be Bug 106305
I agree with Dirk - we are going for a more general solution to this issue.
