Community
Participate
Working Groups
20030813 i'd like to be able to remove/hide certain nodes from the view. motivation: sometimes after exploring the graph for a while i realize that a branch is not interesting for me and i'd like to remove it from the view to reduce the clutter
assigned to Markus because he's taking over as Jesper's buddy on this feature
When you say certain nodes, does this mean a specific node or does it include all occurrences of a multiply occurring part of a call hierarchy?
both. it should be a preference settable on the view (it could also ask me every time but that'd be more annoying)
Or, right-click on the node, and have two different options: Hide This Node Hide All Occurances Of This Node
FWIW, I just hacked in an option to my newbie Callgraph plug-in that will remove nodes. see http://clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/CallGraphEclipsePlugin Problem is, the code to remove a node from a Tree class is package protected -- the only public method appears to be removeAll(), which is a weirdness of the Tree class, IMO. Anyway, my hack has a copy of the destroyItem() code, but much of it can't be compiled outside the class, so it 'works' for removing the TreeItem (handle is public), but the internal items[] array is not updated, which leads to weird side-effect bugs (click on a new node after removing another one, and the editor takes you to the removed method) and certainly resource leaks. Maybe we need a request item for Tree to get a public removeItem() method -- unless there's one there and I'm just blind.
re comment 5: TreeItem.dispose can be used to remove items from trees
(In reply to comment #6) > re comment 5: TreeItem.dispose can be used to remove items from trees Ah, right. Excellent. So far in my plug-in adventure, everytime something seems stupid, it turns out to be me. :-)
*** Bug 101742 has been marked as a duplicate of this bug. ***
*** Bug 131110 has been marked as a duplicate of this bug. ***
3.5 M7 if time permits, 3.6 otherwise.
Raksha, when having free time you can (continue to) work on this but since it's feature work we won't add it to 3.5.
Created attachment 139751 [details] Patch with the fix. Added an action "Remove from View" to the context menu of nodes which are MethodWrapper instances. It removes any particular node and all its children, and removes the parent node too -if all of its children nodes were removed already. Action is * Added for [constructor] node * Added for multiple selections * Not added for "..." node * Not added for nodes whose children are currently being fetched. (Here, I tried another approach where we cancel all the current running jobs on the selected method wrapper and then dispose the node. But that causes a refresh of the node by which time it is already disposed causing a SWT Unhandled event loop exception on that widget) org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed) at org.eclipse.swt.SWT.error(SWT.java:3884) at org.eclipse.swt.SWT.error(SWT.java:3799) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) 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(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287) Caused by: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3884) at org.eclipse.swt.SWT.error(SWT.java:3799) at org.eclipse.swt.SWT.error(SWT.java:3770) at org.eclipse.swt.widgets.Widget.error(Widget.java:463) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:336) at org.eclipse.swt.widgets.TreeItem.setExpanded(TreeItem.java:1188) at org.eclipse.jface.viewers.TreeViewer.setExpanded(TreeViewer.java:331) at org.eclipse.jface.viewers.AbstractTreeViewer.setExpandedState(AbstractTreeViewer.java:2435) at org.eclipse.jdt.internal.ui.callhierarchy.CallHierarchyContentProvider.collapseAndRefresh(CallHierarchyContentProvider.java:337) at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper$1.run(DeferredMethodWrapper.java:86) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) ... 23 more
>and removes the parent node too -if all of its children nodes were removed >already. I don't like that, it's unexpected if the view suddenly goes blank when deleting a child node. And some bugs to fix: - Selecting a parent and a child node and then 'Remove from View' causes exceptions - RemoveFromViewAction should be package visible only - The action should not have an icon - I don't understand the "hideNode" in the message keys - The mnemonic 'R' is already in use. Take one that's not in use yet.
(In reply to comment #13) > >and removes the parent node too -if all of its children nodes were removed > >already. > I don't like that, it's unexpected if the view suddenly goes blank when > deleting a child node. > This would happen only if all nodes of the tree contains single child. If there are multiple branches then removing the parent nodes(which would become leaf nodes after removing their children) would make the tree more clearer, since those nodes cannot be expanded any further. If we plan to keep the parent nodes , then should we collapse and refresh them , so that they can be expanded again if needed?
>if there >are multiple branches then removing the parent nodes Can you provide an example so I can quickly get a picture/idea of it? Most of the time I'm reluctant to auto-collapse or remove anything.
(In reply to comment #15) > >if there > >are multiple branches then removing the parent nodes > Can you provide an example so I can quickly get a picture/idea of it? Most of > the time I'm reluctant to auto-collapse or remove anything. > It could be any constructor call, where you explore into its depths and want to remove it from the view because you are not interested in it anymore. Since we have disabled the parent/child selection, the user might have to go all the way up to remove the entire sub-branch. So if we add a check there for leaf parent nodes , then removing any node in that hierarchy will do the trick, and then the user can easily move over to other constructor calls that are of interest.
Created attachment 140178 [details] Patch with review changes.
>- The mnemonic 'R' is already in use. Take one that's not in use yet. I really meant what I said: Take one that's not in use yet. Why did you replace it with 'O' which is already used by the very first menu entry? I've committed the patch with a better mnemonic so we can continue on a smaller patch. Those problems still need to be addressed: > Since we have disabled the parent/child selection, Why? This should be possible and was possible in your first patch (even though it threw an exception). Please fix this. [callers] node cannot be removed. Please remove the auto-removal. As said, I don't like it. I might have drilled down and not yet looked at the reference in the top node but suddenly my node gets remove. Bad.
Created attachment 140836 [details] Refined patch
Patch is good. Fixed three things I previously missed: - fixed broken formatting / superfluous whitespace in the run() method - removed unneccessary items[i].isDisposed() - replaced for-loop over iterator with a while-loop (we prefer this)
Verified for 3.6 M1 using I20090803-188 on Linux-GTK.
>Verified for 3.6 M1 using I20090803-188 on Linux-GTK. ...using I20090803-1800...
