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.
Goal is to provide API which is able to inform clients: 1) when node's children are going to be obtained 2) when node's children are fully obtained and complete Original motivation is ability to provide progress mouse cursor feedback to the user during folder expand in the explorer's tree. for the original request please see issue 27777, comment from Jeri Lockhart.
Rather than providing an ad-hoc API just to listen to start and finish, I suggest Tim's recommendation we taken seriously at this point: a way for a Children object to supply nodes incrementally or in ranges, much as e.g. Swing's ListModel and TreeModel do. This could provide performance benefits such as not computing off-screen nodes, in conjunction with other changes. It should encompass addNotify/removeNotify semantics, getNodes(true) and the findChild(null) idiom, listening for completion, and requests for expected child list size and for indexed subranges. Looks, Filesystems, and Datasystems might all be affected somehow. In the nearer term, Datasystems already produces folder children incrementally.
Children.addNotify()is not called early enough for an effective cursor change. In my worse-case test, if I set the cursor in addNotify(), there's a delay of several seconds between the user expand action and the cursor change. I've put pairs of set/reset calls in four other places, in addition to addNotify(). This creates an on-off effect, instead of a steady cursor. Admittedly we have a performance problem. This request, however, is asking for a way to improve responsiveness. Even after improving performance we may still want to do a cursor change and will need an API. Another disadvantage of the piecemeal workaround described above is that I am not able to set a "Please Wait" node, but must use the cursor change. I'm bumping this up to a P2 because I feel that the workaround that I have is not entirely acceptable.
Created attachment 8546 [details] Test for the node expansion performance
Adding the API for wait cursor is not easy. We would have to extended the contract between nodes and views. However I'm attaching a test which (when run using internal execution) shows how long takes the expansion i.e. how much time is spent between TreeWillExpand and addNotify, between setKeys and createNodes and between create nods and TreeExpanded. It looks that the addNotify() should be OK for enabling the wait cursor. It happens almost imediately after TreeWillExpand ( 1- 10 miliseconds).
One of the first of our methods called after treeWillExpand is com.sun.forte4j.j2ee.appasm.AsmDataObject.delayedInit() via FilterNode.getOpenedIcon(). Then methods for the J2EE modules in the application get called (com.sun.forte4j.j2ee.ejbmodule). Near the end AsmDataObject.addNotify() is called, 11.927 seconds after treeWillExpand(). I'll attach 2 logs, one for expanding an app node with one module and one for an app node with 6 modules.
Created attachment 8569 [details] expanding app node with one module: log with timestamps & call stacks
Created attachment 8570 [details] expanding app node with 6 modules: log with timestamps & call stacks
After following Petr's suggestion of postponing long-running work from getOpenedIcon() until addNotify() I was able to eliminate the delay in showing the wait node (Thank you, Petr!). So now that I am able to use addNotify I don't have a particular need for this enhancement. But I'll leave it to Petr what status he wants to give it, in light of Jesse's comments of 7 Jan.
Could be useful in nodes_eq_35833 branch.
Taking over the node bugs from phrebejk.
This enhancement seems to be irrelevant now. Petre, please close it if you agree.
Cf. my comment from 2003, probably partially implemented by Yarda's lazy nodes work?
In the lazy branch, I am able to return the number of children and then return one by one when someone asks. Which is imho what you described in your comment from Jan 7 23:14:11 +0000 2003
Actually in 2003 I suggested something a bit more complicated, but I believe that the impl in Yarda's lazy branch is probably adequate for our needs; there is no real need to show a wait cursor if you are not even going to try to compute off-screen nodes to begin with. There could still be circumstances, however, where the act of computing the *keys* (not just the nodes) is very time-consuming and it would be desirable to show a wait cursor until that is done. Or maybe Yarda's lazy API handles this sensibly too, I don't remember.
My patch diferentiates between slow&fast children. Fast are those that use the new constructor Children.Keys (int nodesPerKey). Those expand without any user indication. All the other still use the wait mouse cursor.
Reassigning to new module owner Tomas Holy.
The API is Children.getNodes(true)