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.
No progress indication, wait cursor should be implemented and used consistently throughout NetBeans http://www.netbeans.org/servlets/ReadMsg?msgId=384459&listName=nbdev
Will we try to implement some kind of automatic wait cursor need detection and showing? Or will we use this issue as a top issue for individual cases (issue) where the wait cursor should be used explicitly?
Yes, I will try to detect automatically if AWT is busy, if event being dispatched longer then 100-200ms (will be set after empiric testing). However I must be careful to keep automatic watching lightweight, perhaps start watching only when some action starts its performAction. Even if automatic watching will succeed, I expect that there will be some cases where setCursor() will have to be called explicitly. Your thoughts, Tomas?
I think we should try this first - to see if it is possible. I have some doubts if monitoring AWT EventQueue is reliable enough, especially with watching performAction first. At least, actions are not started in AWT, there can be significant time spent in non-AWT thread first, then some time in AWT - but at the point it's already late to display wait cursor (I think opening files could have such profile). So the time when AWT is blocked need not correspond fully to the time the user must wait... Anyway, these are just speculations, let's try to do something first.
I asked Tom Ball of SunLabs his opinion of using the UI event dispatch queue for setting a wait cursor, as suggested in this JavaWorld article. http://www.javaworld.com/javatips/jw-javatip87_p.html I'm taking the liberty of passing on his remarks and reasons for not recommending this approach. Also want to mention that a new cursor has been added to openide.util.Utilities - a "Progress Cursor" that is a cross between the default arrow cursor and a wait cursor. The progress cursor can be set by module writers during long running tasks to indicate to the user that some background activity is happening, but that other parts of the IDE are still responsive. Here are Tom's comments about using the event queue: "I am not very enthusiastic regarding this proposal of having the EventQueue manage "progress cursors", however. On the surface it sounds great, but I have two concerns. First, event handling is supposed to be fast, so blocking the system event queue is usually a bad idea. The user is supposed to be in control, and it's the event queue which forwards that control through input events to the application. Tasks which take longer than a few milliseconds should normally be run in a secondary thread so the UI remains fully responsive. A component which fires up such a task might well set the "progress cursor" you describe, but I don't think that the event dispatching system should do so. Take a modern browser, for example; I'd expect its HTML pane to set the cursor while the page loads, and not the system's dispatching queue. Which code is more likely to know when the page is finished loading? The event queue only knows that the event handler has exited, but not why. The HTML pane might separately load and then reformat the page using two events, so putting the cursor back to normal before the reformat (which might also take awhile) would be misleading. Secondly, what will the performance impact be on event handling? Since every event dispatch pays a small price, does the total price outweigh the benefit of not fixing a few poorly implemented procedures? I think a better use of a EventQueue extension is a diagnostic tool which times each event and prints, logs, fires an exception or dials 911 whenever a component's event handler takes too long. What's too long? I don't know, but perhaps Trung's 100 ms. time is a good starting point. Regardless, I'd much rather see the offending event handlers get fixed or rewritten than slowing the system down to accomodate their poor design. I'm also quite willing to help you and/or the NetBeans performance team track down these offenders."
*** Issue 22890 has been marked as a duplicate of this issue. ***
I recommend these usage of cursors: -Displaying Busy cursor (hourglass) over all application, when users are (or could be) blocked from interaction with the application. -Displaying Wait cursor (arrow with small hourglass) only over part of IDE which is blocking user's interaction. -Displaying Busy cursor when opening all dialogs, not only "slow" ones. -Anytime text 'Please Wait...' or similar is displayed the wait or busy cursor needs to be used.
Created attachment 8967 [details] patch which shows busy cursor during action processing
I think the patch works correctly. It is not ideal, but responsiveness has been improved a lot with the patch. This is the summary: 1. Patch displays the wait cursor for an action which display a dialog through NB APIs (DialogDisplayer, I guess). The cursor is switched back when a dialog is displayed. That is good. 2. When a dialog is displayed without using DialogDisplayer, the wait cursor stays even if the dialog is already displayed (File|Page Setup, File|File Open). That is a problem and should be fixed. 3. Actually almost each invoked action activates the wait cursor, even if it is invoked by keyboard. This is good, but the problem is that the cursor is the blocking cursor. Ideally the cursor would be non-blocking if the action is non-blocking, otherwise it would be blocking. Blocking action is the one, which opens a modal dialog. For 3.5, I propose to change the blocking wait cursor to non-blocking progress cursor for all actions. 4. Some long time taking actions (CVS, Compile) does not provide any feedback (no wait cursor is displayed) or just a partial (wait cursor is displayed at the start of the action and then switched back, without knowing why from the user point of view), what might confuse the user. Don't know the solution yet :-(.
Created attachment 9051 [details] refined patch in binary form
put binary patch in lib/patches, should work with dev builds. Patch solves defect #2 mentioned above, #3 in suggested way for 3.5 (non-blocking cursor user for all). Don't mix this patch with older one. #4 isn't solvable now IMO. It needs support from the side of author of action, which also means we should provide API for them or they will have to hack explicit setCursor calls into their code - not good now. Needs to be solved later together with general progress API I think.
Created attachment 9053 [details] correct patch
I'm sorry, a class was missing in previous patch. Now it should be ok. Sorry for inconvenience.
Patch integrated into main trunk. http://core.netbeans.org/source/browse/core/src/org/netbeans/core/ModuleActions.java.diff?r1=1.26&r2=1.27 http://core.netbeans.org/source/browse/core/src/org/netbeans/core/ui/MouseCursorUtils.java?rev=1.1&content-type=text/x-cvsweb-markup Impl works as follows: - non blocking wait cursor is set whevever some action starts to be executed - cursor is reset when soem of following happens: a) action finishes its execution b) some window or dialog is opened, no matter if through DialogDescriptor or not
HIE response: Current solution is working very good in most cases. Follow few cases when it fails (for the future reference): 1. Progress cursor is switched off too early without any visible end of the action. An example is "View|Debugger Window" action. Each of such actions should be fixed individually. 2. Progress cursor is switched off for a *long time taking* action without a proper notification about the next progress of the action. So it seems like the action finished without any result. An example is compile action. This should be fixed generally by a suitable progress notification mechanism. 3. Progress cursor is *not* switched off during long time taking action. This is a hypothetical problem of current solution. The problem would be visible in the editor or other components which provide their own cursor. So during the whole action the cursor would be incorrect. This should be fixed individually and with the global progress notification.