Goal is to provide API which is able to inform
1) when node's children are going to be obtained
2) when node's children are fully obtained and
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
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
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
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
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)