This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 35399 - request for public accesses for VisualizerNode class
Summary: request for public accesses for VisualizerNode class
Status: VERIFIED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P1 blocker (vote)
Assignee: issues@debugger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-12 21:07 UTC by Chihin Ko
Modified: 2003-12-11 14:20 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chihin Ko 2003-08-12 21:07:38 UTC
request for public accesses for following data
in openide module:

org.openide.explorer.view.TreeView.tree 
org.openide.explorer.view.VisualizerNode class 
org.openide.explorer.view.VisualizerNode.node 

This is for Rainier EA, dated 8-25-2003, should
be done ASAP.
Comment 1 Jiri Rechtacek 2003-08-13 14:00:08 UTC
It is a violation on Explorer API, these classes and fields are
invisible to avoid force or abuse it. It cannot be changed IMHO (I'll
close as WON'T FIX, If I'm wrong, reopen) Reporter, could you specify,
why you are need access them? What part of code for RAINIER ask it?
Yardo, could you comment it? Thanks
Comment 2 _ gordonp 2003-08-14 21:45:22 UTC
Jean (Chinin) is having trouble staying loggen into
netbeans and cannot post her response to your closing
this issue. I'll post it in the next comment but want
to put my own comment in as well.

This issue is CRITICAL to Rainier! Without this fix
we have a significant usability problem. If you don't
like Jean's solution, work with her so we have another
way of doing it. One way or another, we need the
ability to update a watch without having it close.
Comment 3 _ gordonp 2003-08-14 21:46:03 UTC
Now for Jean's comments...

dbxGUI in RAINIER_EA need this.

It is for keeping tree state of Variable/Watch Views. 
Without this I'm not able to keep track of latest open/collapsed
tree nodes. Especially for pointer chasing which is very common
for C++/C application. And for every "next" or stop in bpts,
top nodes in above views are flushed away, and new ones 
get regenerated, I could not find any APIs to support keeping
track of tree state.

Here is the codes from my experiment that use these class/data
that I request for public access:

public class DbxTreeView extends BeanTreeView {

    private TreePropertyListener tree_listener = null;
    
    DbxTreeView(TreeView view) {
        tree_listener = new TreePropertyListener();
        view.tree.addTreeExpansionListener (tree_listener);
    }
    
    class TreePropertyListener implements TreeExpansionListener {

	TreePropertyListener() {};

	public void treeExpanded (TreeExpansionEvent ev) {
	    TreePath tp = ev.getPath();
	    Object node = tp.getLastPathComponent();
	    Object root_node = tp.getPathComponent(0);
	    if (root_node != null && node != null) {
		String root_name = ((VisualizerNode)root_node).getDisplayName();
		String name = ((VisualizerNode)node).getDisplayName();
		DbxVariableNode n = (DbxVariableNode)((VisualizerNode)node).node;
		DbxVariable var = (DbxVariable)n.getVariable();
		if (!var.isExpanded()) {
		    //var.setExpanded(root_name, true);
	        System.out.println("treeExpanded open node  " + name);
	        System.out.println("treeExpanded root  " + root_name);
	        }
	    }
	}

	public void treeCollapsed (TreeExpansionEvent ev) {
	    TreePath tp = ev.getPath();
	    TreePath parent_tp = tp.getParentPath();
	    Object node = tp.getLastPathComponent();
	    Object parent_node = parent_tp.getLastPathComponent();
	    Object root_node = tp.getPathComponent(1);
	    if (root_node != null && node != null) {
		String parent_name = ((VisualizerNode)parent_node).getDisplayName();
		String root_name = ((VisualizerNode)root_node).getDisplayName();
		String name = ((VisualizerNode)node).getDisplayName();
		DbxVariableNode n = (DbxVariableNode)((VisualizerNode)node).node;
		DbxVariable var = (DbxVariable)n.getVariable();
		if (var.isExpanded()) {
		    var.setExpanded(root_name, false);
		    var.removeAllDescendantFromOpenList();
	        System.out.println("collapsed node  " + name);
	        }
	        //System.out.println("collapsed node  " + name);
	        //System.out.println("collapsed root node  " + root_name);
	        //System.out.println("collapsed parent node  " + parent_name);
	    }
	}
    }
}


Comment 4 Jaroslav Tulach 2003-08-15 13:27:40 UTC
The original request wanted to make few things public:

TreeView.tree is protected. But DbxTreeView is extending TreeView, so
everything is ok.

VisualizerNode just implements javax.swing.tree.TreeNode and does not
need to be accessed directly.

Conversion from TreeNode to Node and from Node to TreeNode is handled
by static methods in Visualizer class. So there is no need to make
VisualizerNode and its node field public.

This leads me to the same opinion as Jirka expressed. The orginal
request is not valid. Use Visualizer if you want the access you have
described - you can nearly keep the same code as is shown in this issue. 

But if you want to fix this properly implement correctly
Children.Keys.setKeys method to replace the old keys with new ones
that are as much as possible equal to previous values. In my opinion
this is the whole source of the troubles and the solution here is just
a workaround to that original problem.

Comment 5 ivan 2003-08-16 00:25:25 UTC
Let me explain the high level intention and our attempts at it.
In the locals view on can chase pointers. 
On each stoppage there is a new list of locals. 
One can update the Node/Variable tree in one of two ways,
delete everything and recreate everything, or compare the
new set of locals with the existing Node/DO's and add and
remove as neccessary ("delta" algorithm, and what Yarda was
talking about in his last paragraph above).
Let's look at the delete and recreate everything algorithm a 
bit more closely. It would have to:

1) remember all open nodes
2) destroy everything
3) recreate all top-level nodes from the list of locals.
4) reopen all the ones (recursively) that the user had opened.

The crucial part is step 1. It is also needed for the "delta"
algorithm, so let's not pick on the merits of
delta vs delete and recreate now.
There are two ways to get the information for (1):
a) listen and remember 
b) ask 
(Haven't we seen this distinction before :-)
So Jean was exploring (a) and got dragged deep into the
implementation. Taking a step back, we get notification of 
Node expansion via Children.Keys.addNotify. This is a pattern
I learned form debuggercore but I"m uncomfortable with it since 
the javadoc for Children.Keys doesn't mention "turning" explicitly.
So one guess was to see if C.K.removeNotify corresponds to a 
turner closing, but it isn't. So let me ask a series of questions.
- To implement (a) what is the proper way of listening for node
  openings and closing?
- If C.K.addNotify is the proper way, by intent or convention, then
  the RFE is to enhance Children.Key with a proper node closing
  notification.
- Maybe there is no proper way so we might ask for that ...
- Oooor we go the (b) way which requires:
  b.1: A way to traverse the node tree. (I don't know how to do that)
  b.2: Access to a record of whether the Node is open or not.
       A closed Node might still have children that are just not
       being displayed so a child count won't do.
 


Comment 6 Chihin Ko 2003-08-19 00:49:34 UTC
The request for public access of VisualizerNode is not needed,
I'm using Visualizer to get the TreeNode now. 
But the tree is of the view (debugger Variable View in my case)
still need public access:

 
    DbxTreeView(TreeView view) {
        tree_listener = new TreePropertyListener();
        view.tree.addTreeExpansionListener (tree_listener);
    }
    
Comment 7 Jaroslav Tulach 2003-08-20 08:14:36 UTC
Good to hear that we solved at least one problem. 

The main reason for the second one is that you are trying to access
the JTree variable in some TreeView. Well, this is not allowed by the
basic Explorer API for good reason. We do not want code that did not
created the TreeView to do it unless permited by the creator of the view.

If debugger (the creator of the view) wants to permit this
functionality, then it should have a public class
DebuggerVariableTreeView (I do not know what is the actual name of the
class in debuggercore) with a method JTree getTree () and allow you to
call that method.

Reassigning to debuggercore where the requested change shall happen.
Comment 8 Maros Sandor 2003-08-20 11:07:03 UTC
I added a public accessor for the protected field 'tree' 
as requested. You can now get the underlying Swing JTree 
from all debugger TreeViews by invoking:
JTree tree = myWatchesView.myTreeTable.getJTree();

/cvs/debuggercore/src/org/netbeans/modules/debugger/support
/nodes/TreeTableExplorerViewSupport.java,v  <--  
TreeTableExplorerViewSupport.java
new revision: 1.13.8.4; previous revision: 1.13.8.3
Comment 9 Chihin Ko 2003-08-20 21:54:16 UTC
getJTree() is in inner class MyTreeTable, which is private,
I still can not access getJTree().

Sandor, please also make class MyTreeTable public.

Here is my build error:

compile:
    [javac] Compiling 1 source file to
/net/ryan1/export/jeanko/ws/dublin/nb_top/dbxgui/src
    [javac]
/net/ryan1/export/jeanko/ws/dublin/nb_top/dbxgui/src/com/sun/tools/debugger/dbxgui/nodes/DbxTreeView.java:40:
getJTree() in
org.netbeans.modules.debugger.support.nodes.TreeTableExplorerViewSupport.MyTreeTable
is not defined in a public class or interface; cannot be accessed from
outside package
    [javac]        
view.myTreeTable.getJTree().addTreeExpansionListener (tree_listener);
    [javac]                         ^
    [javac] 1 error
Comment 10 Maros Sandor 2003-08-21 09:41:36 UTC
It's now public and your code will work. Maros.
Comment 11 Maros Sandor 2003-08-22 12:40:24 UTC
Ok, I assume it works.
Comment 12 Lukas Hasik 2003-09-04 15:21:11 UTC
verified in trunk rev. 1.15
mark as verified if it's ok from rainier point of view.
Comment 13 Chihin Ko 2003-09-04 19:58:10 UTC
Since Class Visualizer has the APIs that I need for accessing class
VisualizerNode, I don't need class VisualizerNode to be public