Community
Participate
Working Groups
build I20021114 AbstractFilter.isFilterProperty returns true for the text and image properties. This is incorrect and results in unnecessary refreshes in the Package Explorer. isFilterProperty should only return true for properties that can affect the filtering result if their value changes. That is, it should correspond to the properties used in the select method. (Likewise for ViewerSorter.isSorterProperty.) Here is a stack trace of an unnecessary full refresh caused by EmptyInnerPackageFilter.isFilterProperty returning true for the image property: Thread [main] (Suspended) org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4 (org.eclipse.jface.viewers.StructuredViewer).refresh() line: 704 org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4 (org.eclipse.jface.viewers.StructuredViewer).update(java.lang.Object, java.lang.String[]) line: 1099 org.eclipse.jdt.internal.ui.packageview.PackageExplorerContentProvider$2 .run() line: 365 org.eclipse.swt.widgets.RunnableLock.run() line: 31 org.eclipse.ui.internal.UISynchronizer (org.eclipse.swt.widgets.Synchronizer).runAsyncMessages() line: 94 org.eclipse.swt.widgets.Display.runAsyncMessages() line: 1669 org.eclipse.swt.widgets.Display.readAndDispatch() line: 1414 org.eclipse.ui.internal.Workbench.runEventLoop() line: 1435 org.eclipse.ui.internal.Workbench.run(java.lang.Object) line: 1418 org.eclipse.core.internal.boot.InternalBootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[], java.lang.Runnable) line: 831 org.eclipse.core.boot.BootLoader.run(java.lang.String, java.net.URL, java.lang.String, java.lang.String[]) line: 432 EclipseRuntimeLauncher.main(java.lang.String[]) line: 24 The steps that caused this can be found in comment #13 of bug 3840 (I was deleting Class 1), leaving an empty default package.
The extra refreshes are a performance hit.
The call to update in the stack above is in PackageExplorerContentProvider.postUpdateIcon.
This is being called by processDelta, which also tries to handle the switch to an empty package (after attempting to update the icon). The icon will be updated by the call to refresh the parent anyway. (I also noticed that this calls element.getParent() in one place and internalGetParent(parent) elsewhere, that internalGetParent(parent) is called twice here, and that the call to isPackageFragmentEmpty is outside the instanceof IPackageFragment check. Not sure if any of these are real problems.)
analysis is correct filters should no never depend on the label or the image. I've removed the override and left the base class in for now. The calls of getParent vs. getInternalParent are OK. The reason for this complexity is caused by the Java Model's representations of the project's package fragment root that we have to filter out in the content provider.
Cleaned up code; removed AbstractFilter
