Community
Participate
Working Groups
ResourceExtensionContentProvider and WorkbenchContentProvider do not support IResourceDelta.CONTENT changes to indivdual files. We are implementing a navigator built on the Common Navigator Framework (CNF) that overrides the 'org.eclipse.ui.navigator.resourceContent' navigator content extension (/org.eclipse.ui.navigator.resources/src/org/eclipse/ui/internal/navigator/resources/workbench/ResourceExtensionContentProvider.java content provider). When a the content of a targeted file is updated in the local workspace, the /org.eclipse.ui.navigator.resources/src/org/eclipse/ui/internal/navigator/resources/workbench/ResourceExtensionContentProvider.java does refresh the individual file (instead refreshing the directory containing the file), which is required by implementation of a IPipelinedTreeContentProvider content provider. Note, the same fix would apply to the /org.eclipse.ui.ide/extensions/org/eclipse/ui/model/WorkbenchContentProvider.java content provider.
Created attachment 122145 [details] Patch for WorkbenchContentProvider.java.
Created attachment 122146 [details] Patch for ResourceExtensionContentProvider.java.
Wouldn't refreshing the directory on every change be expensive? PW
(In reply to comment #3) > Wouldn't refreshing the directory on every change be expensive? > > PW > The proposal is to refresh every file. The code currently refreshes the parent directory, which could be optimized once this patch is applied.
It's certainly a big potential new cost. Think of operations like big workspace builds, that currently make no structural changes and thus have very little overhead for WorkbenchContentProvider. Once you also consider content changes you are introducing a very large number of new refreshes, which many clients of WorkbenchContentProvider don't care about. Minimally this should be optional behavior controlled by some flag, so that only trees that are affected by content changes get the refreshes (such as your custom navigator). WorkbenchContentProvider is API with a large number of existing clients, who should *not* be getting extra refreshes unless they opt into it.
(In reply to comment #5) > It's certainly a big potential new cost. Think of operations like big workspace > builds, that currently make no structural changes and thus have very little > overhead for WorkbenchContentProvider. Once you also consider content changes > you are introducing a very large number of new refreshes, which many clients of > WorkbenchContentProvider don't care about. Minimally this should be optional > behavior controlled by some flag, so that only trees that are affected by > content changes get the refreshes (such as your custom navigator). > WorkbenchContentProvider is API with a large number of existing clients, who > should *not* be getting extra refreshes unless they opt into it. > I would agree. A flag would be the best route.
Paul, would you mind revising your patches to include some kind of flag?
(In reply to comment #7) > Paul, would you mind revising your patches to include some kind of flag? > Sure when I return to the office (out this week at a customer site) on 01/19 (earliest).
The code currently refreshes the parent based on marker changes; so the actual changes that occur for content on a large build would be the same for most Java workspaces that have their warnings/compilation flags updated during the build. Alternatively to adding code strictly for IFiles, you could rely on the code that supplies a refreshable for the parent; again for most files the save would potentially update markers and content; it happens that Paul's example doesn't update the markers. The Resource Extension that handles notifying trees is already optimized to queue a batch of refresh actions as a result of processing a delta, so they occur with minimal impact on the UI.
Michael, I don't see where it is responding to marker changes in either WorkbenchContentProvider or ResourceExtensionContentProvider... where does this happen?
(In reply to comment #8) > (In reply to comment #7) > > Paul, would you mind revising your patches to include some kind of flag? > > > > Sure when I return to the office (out this week at a customer site) on 01/19 > (earliest). > Francis, unfortunately, I will not be able to contribute any resources to revising the attached patch.
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.
