Bug 216866 - Problems view shows empty categories when 'group by' is enabled
Summary: Problems view shows empty categories when 'group by' is enabled
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P2 minor (vote)
Target Milestone: 3.1   Edit
Assignee: Mik Kersten CLA
QA Contact:
URL:
Whiteboard:
Keywords: noteworthy
Depends on:
Blocks:
 
Reported: 2008-01-29 02:48 EST by Robert Munteanu CLA
Modified: 2009-03-04 22:28 EST (History)
1 user (show)

See Also:


Attachments
Filtered problems view with group by type enabled (38.24 KB, image/jpeg)
2008-01-29 02:48 EST, Robert Munteanu CLA
no flags Details
mylyn/context/zip (37.01 KB, application/octet-stream)
2009-02-26 14:14 EST, Mik Kersten CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Munteanu CLA 2008-01-29 02:48:06 EST
When focusing a task, and filtering the problems view with 'group by type' enabled, empty categories are shown.
Comment 1 Robert Munteanu CLA 2008-01-29 02:48:56 EST
Created attachment 88103 [details]
Filtered problems view with group by type enabled
Comment 2 Mik Kersten CLA 2008-02-26 01:19:29 EST
While there is some utility to this (you know what you're missing) I agree that it would be better to hide empty containers.  Need to postpone to 3.0.
Comment 3 Mik Kersten CLA 2008-06-13 17:59:42 EDT
This requires the Eclipse Platform changes to make MarkerCategory accessible.  Deferring to 3.1, but leaving as high priority in order to encourage Platform early on.
Comment 4 Mik Kersten CLA 2009-02-26 14:14:15 EST
Fixed.
Comment 5 Mik Kersten CLA 2009-02-26 14:14:18 EST
Created attachment 126885 [details]
mylyn/context/zip
Comment 6 Mik Kersten CLA 2009-02-26 14:17:07 EST
Steffen: As noted in the code, this solution has O(n^2) complexity, since we need to look down the children to find the interesting ones.  I think it's generally OK to do this with table views that are categorized, but we should continue to avoid this kind of algorithm for tree views.  

We'll need to check the performance when there are tens of thousands of markers, but thankfully the views' own limiting of the number of markers shown will be on our side with respect to scalability.

Please tentatively add this to the Noteworthy since it will make focus for the Markers view considerably more useful.
Comment 7 Steffen Pingel CLA 2009-03-04 18:55:35 EST
I think this change has severe performance implications:

"main" prio=10 tid=0x08059000 nid=0x17cd runnable [0xb7d6b000..0xb7d6d208]
   java.lang.Thread.State: RUNNABLE
	at org.eclipse.jdt.internal.core.util.Util.isJavaLikeFileName(Util.java:2627)
	at org.eclipse.jdt.internal.core.JavaModelManager.determineIfOnClasspath(JavaModelManager.java:958)
	at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:856)
	at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:786)
	at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:2534)
	at org.eclipse.jdt.internal.ui.ResourceAdapterFactory.getAdapter(ResourceAdapterFactory.java:44)
	at org.eclipse.core.internal.adapter.AdapterFactoryProxy.getAdapter(AdapterFactoryProxy.java:80)
	at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:293)
	at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66)
	at org.eclipse.mylyn.internal.java.ui.JavaStructureBridge.acceptsObject(JavaStructureBridge.java:207)
	at org.eclipse.mylyn.internal.context.core.ContextCorePlugin.getStructureBridge(ContextCorePlugin.java:256)
	at org.eclipse.mylyn.context.core.ContextCore.getStructureBridge(ContextCore.java:41)
	at org.eclipse.mylyn.context.ui.InterestFilter.select(InterestFilter.java:65)
	at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isFiltered(ProblemTreeViewer.java:310)
	at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.isFiltered(PackageExplorerPart.java:275)
	at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.containsNonFiltered(ProblemTreeViewer.java:291)
	at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.hasFilteredChildren(ProblemTreeViewer.java:256)
	at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isExpandable(ProblemTreeViewer.java:244)
	at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:2108)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1705)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1718)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1718)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1718)
	at org.eclipse.jface.viewers.AbstractTreeViewer.expandToLevel(AbstractTreeViewer.java:1054)
	at org.eclipse.jface.viewers.AbstractTreeViewer.expandToLevel(AbstractTreeViewer.java:1035)
	at org.eclipse.jface.viewers.AbstractTreeViewer.expandAll(AbstractTreeViewer.java:1024)
	at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager.updateExpansionState(FocusedViewerManager.java:279)
	at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager.access$1(FocusedViewerManager.java:272)
	at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager$FocusedViewerDelayedRefreshJob.doRefresh(FocusedViewerManager.java:97)
	at org.eclipse.mylyn.internal.provisional.commons.ui.DelayedRefreshJob.runInUIThread(DelayedRefreshJob.java:96)
	at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
	- locked <0xafa3c918> (a org.eclipse.swt.widgets.RunnableLock)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3452)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3099)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2388)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2352)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2204)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:499)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:333)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:492)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:556)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:511)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1284)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1260)
Comment 8 Steffen Pingel CLA 2009-03-04 22:28:44 EST
Sorry, wrong bug. This seems to be unrelated to the change in question. I have opened bug 267143 to track this.