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.
Not sure what is right module to assign but it looks like result of some user responsivness work to me. (Though not sure.) When Options is opened nodes are displayed collapsed and then after few seconds nodes are expanded. (This happens when Options is displayed for the first time after IDE start.) There is no UI about expanding. If user clicks on some collapsed node he actualy clicks on some node which will be at given point when expanded. It can be really confusing for NB unexperienced user. Current dev build 200309100100, JDK 1.4.2, Linux RH 8, KDE.
CCing Jesse and Jarda If they have any comments about this. I remember Jarda did some changes in this for 3.5.
Jirka it should be problem of your #35792.
Yes, it seems Marek found a way how to reproduce #35792 manually. Would you like to join QA team Marek? :-)) Anyway, issue #35792 appeared in build 20030908-0621. Jesse did changes of threading before that, so he could probably know how to fix it.
Well it could be changed. Previously Tools -> Options just waited for a couple seconds with no window open (status line message only), computing the subnodes, then opened the window with everything expanded. Now it shows the window immediately and then expands nodes to level 3 right after (acc. to JLF principle of displaying critical info right away and the rest as soon as possible thereafter). Reason for change involves threading of node expansion - if you expand the nodes in the background with the window closed, I found it does not feel good to use, whereas it felt much better (to me, after some experimentation) to simply open the window right away. I'm not sure what the problem is, actually.
IMO problem is that user is allowed to interact with something which is not yet displayed: 1.Collapsed nodes are displayed 2.User clicks on some node to expand. 3.Nodes are expanded. 4.NOW previous user clicks is processed on currently visible node where used clicked. It is wrong. I think user interaction should be blocked (if possible) AND user should be notified by busy cursor that window is not ready yet to process user input. Otherwise I think it is better not to display anything till user input will be interpreted correctly. ie. in this case user click is processed on node visible at moment when user clicks NOT on some node visible sometimes in future. I hope it is clearer now. (Of course it is just my personal opinion. :))
Yes, I think that tree should not be visible or at least enabled until nodes are expanded.
Agreed w/ comment in stage #4 that clicks should be applied to what is shown at the time of the click, of course. Will look at that aspect. Should be possible to set a busy cursor and block input during the expansion period, I didn't think of that.
BTW, I recall similar problem when testing new wizard. For example: - open File|Mount Filesystem - tree of available filesystem types is shown - now a quick user or test can select some node - IDE selects last selected type and it can change user's decision Similarly for templates. And even more generally for all cases where IDE restores remembered value of tree selection.
I didn't touch any other wizards, only Options. There might be some general problem in explorer selections that my change triggered, I have no idea.
I don't think you influenced wizards by your changes. Wizards worked as I described even before your changes. But it seemed to be not such "visible" problem as in Options where selection opens property sheet. I only wanted to say that there should exist some UI recommendation that user interaction with a tree should be enabled only after IDE finishes its initialization (expanding, selecting, ...).
"there should exist some UI recommendation that user interaction with a tree should be enabled only after IDE finishes its initialization (expanding, selecting, ...)" - certainly if the initialization involves selecting something, yes. If the initialization only involves expanding something, as I think is the case here, probably it is some kind of a bug if the expansion cancels or modifies a user selection gesture. However this problem might be inherent in Swing (or just JTree), so the simplest thing would probably be to block all UI input events until the tree is quiescent.
Should just be assigned to me I guess. Also issue #35972 is exactly the same thing.
*** Issue 35972 has been marked as a duplicate of this issue. ***
Wouldn't a "please wait" node followed by the fully expanded tree do the trick? If we are going to kill the options dialog, I don't s'pose it matters much.
The trick is that the expansion is happening in EQ so the "Please wait" might not be painted. I did initially try to do something very much like that (using status bar), but it just did not work as I expected and I did not figure out why. (Calling paintImmediately on the status bar *would* probably work but I am looking for a solution that does not require that call; I *did* try posting the expansion job into EQ under "paint" priority, which should have permitted the status bar to paint even without paintImmediately. For some reason that didn't work, even though the same technique can be seen working smoothly in threaddemo, and I didn't spend much time investigating what went wrong.)
Strange that the please wait icon would not be painted, but the closed folders do get painted... Well, you could provide a dummy tree model, and then swap in the real one when it's completed resolving in another thread...then again, that's probably more trouble than it's worth.
You may be right about the closed folders... I'll give it a try.
If you are able to detect when resolving of nodes is completed then you can show the tree (or tree table) disabled (setEnabled(false)). It prevents component from premature user's mouse clicks. Once the resolving is completed, you call setEnabled(true). IMO, it would do the same trick as "please wait" node, or dummy tree model. Or am I wrong?
Will try for 3.6
The options dialog have to be rewritten in the mean time, as now, it displays full-size "Initializing settings..." label, and then redraws directly to fully expanded tree.
closed