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.
Behaviour changed when issue 58513 was fixed. IMO indeterminate progress indication is strange when debugger stops at breakpoint. I haven't find this use case in UI specification: http://ui.netbeans.org/docs/ui/progress_indication/progress_indication_spec.html#Short_time_tasks_solution
Issue #58513 requests that each Ant process shows a progress task, and that is what I implemented. If you want to change the UI spec, please define how it should behave instead; perhaps I would have time to implement changes.
Oops.
Meant WONTFIX.
Reassigning to HIE. Please, keep this issue open until this use case is included in UI specification.
Moving indicator is distracting me, when I debug anything. HIE suggested to change red marking of changed values in watches as it was too agressive, so now users has to watch the watches view very carefully when stepping through code. But right under Watches view is a moving progress indicator, which distracts eye and is even more agressive. The indicator is OK, but I do not like the fact, it is moving permanently.
I would agree that the animation on the progress bar doesn't accomplish much. However the progress API provides no facility to disable this animation.
Please also bear in mind that there are two separable components to issue #58513: 1. Do not show Output Window immediately when an Ant process begins; show it only if and when a hyperlink is printed for the first time (or an input field or input dialog appears). 1a. With an Options dialog addition to permit the user to choose the 4.1 behavior, i.e. always show it. 2. Register an indeterminate progress task for the Ant process.
Some more background on the alternatives. Q: Does it really mean, that for all project types Ant can't recognize that building finished and tell progress to be disabled, because the running starts? A: Right, from the Ant perspective there is just a process which starts, runs for a while doing some stuff, and then finishes. "Building" and "running" are just conventional terms we use for Ant targets which behave in certain ways, but there is no strong technical difference. The Ant script could be filing your taxes for all the IDE knows about it. There might be some <java> task that is run to start the user's application, for example in j2seproject's Run Project, but other projects may just use this as a build step (e.g. I think Compile JSP does), and not all projects use this task to start a user app (e.g. NBM projects use <exec>, and I have no idea what sophisticated J2EE apps use). Q: Can this problem be solved with issue #43072? Mostly solved, with cooperation from every project type. Invoking an action using the menu/toolbar/key bindings (like Build Main Project or Run Main Project), in which case control passes through the project, could signal to the ant module whether or not an animated progress bar is desired. (The Progress API would still need to be enhanced to support nonanimated indeterminate progress, unless you wanted to remove the entire progress indication for these processes.) A bonus would be that we could control the title of the output window using the same API. Invoking the same Ant target directly from build.xml would still count as a generic process and so always have a progress indication (and title based on the Ant target only). For freeform projects, the Run and Debug actions if invoked on the project could disable progress animation; other standard actions (Build etc.) and custom actions (Process with XDoclet, whatever you have personally configured) would have progress animation. A different tactic would be to adopt a documented but implicit API consisting of some magic keyword that if printed from an Ant task (like <echo>), even at "Verbose" or "Debug" level (so not normally visible to the user), would turn on or off progress animation (again, assuming the Progress API were enhanced with a new method to control this) - with the initial state being "animate", as now. Then the build scripts for standard project types (j2seproject, webapp, NBM, etc.) would include an <echo> task before and after any targets which run (or debug) the user app, to turn on and off animation. Freeform projects would not benefit unless the user added such an <echo> message to their own Ant scripts - harmless but an added burden. A bonus is that issue #41252 would become easier to implement; and it might be possible to fix issue #56921, but I doubt it. Neither approach is trivial and neither can be solved just in the Ant module; requires cooperation from every Ant-based project type. I might (much more simply) suggest disabling animation on any indeterminate progress task which has been running for more than ten seconds or so. After that point, the user is probably not sitting there staring at it and waiting anyway, so why include a distracting animation? Not sure how to turn it off without giving the impression that it was halted. Maybe just slow it down more and more and then finally stop it. Processes which insist on keeping the animation running for longer could perhaps call ProgressHandle.switchToIndeterminate() periodically.
Thanks Jesse for your answers. It looks that the best way to solve this case and similar ones is to enhance Progress API to provide possibility to disable the progress bar. I will file the enhancement.
"The Progress API would still need to be enhanced to support nonanimated indeterminate progress, unless you wanted to remove the entire progress indication for these processes." IMHO hard to accomplish. The animation is fully under the control of the look and feel for a particular platform. There's no way to influence that other than write the our own progress component and/or our own impl of L&F for the bar for all supported platforms. So stopping it or slowing it down sounds good it theory, however it means we invest great effort in writing/maintaining our own UI classes which will not match the native ones. Especially visible on macosx I think where apple uses some kind of image to render the bar. one possibility could be to replace the indeterminate progress with something else like some text, picture, animation etc... but should be visually different from the actual progress bar component visualization. the general rule about keeping track of "active" progress tasks is fine with me, pinging could be done by calling the switchtoindeterminate() or progress("") methods. maybe we should add a progress() method without any parameters to indicate the ping. BTW: i'm sure there are many tasks now that would not be happy about the 10 seconds pinging rule though, like deployment, starting/stopping server etc..
Re. slowing or stopping progress bar: or just remove the progress bar from the status line. The user can still see it (with animation) in the full processes list. Re. how to mark "long-running indeterminate progress" - could be a new API method like switchToIndefinite() which would be like switchToIndeterminate() but would show no progress bar; and Ant would always call this after some timeout defined in the Ant module. (It could even be smarter and start the timeout not after the Ant process started, but after the last event was sent to an AntLogger - and if a new event comes in, switch back to regular indeterminate mode and reset the timer.)
+1 I like what Jesse suggests in the last comment.
Any progress on making a decision (excuse the pun)? If the current behavior is really considered to be worse than 4.1's, and we do not think we can enhance the Progress API in 5.0 to do what we really want, then I suppose we should revert the progress-related half of #58513 before beta.
I guess it could be possible to add an API in the fcs timeframe, not for beta though. if decided to go that way, please file an issue against core/progress.
I am OK with enhancing the progress API in the FCS timeframe. If there are no objections, I will file the issue. The current behavior is really worse than in 4.1, so I suggest reverting changes requested in issue #58513 for beta until the progress API is enhanced.
"so I suggest reverting changes requested in issue #58513" - I guess you mean just the display of the Ant process as a task, but not the changed (default) semantics as to when the Output Window should be opened?
Jesse, I think we should revert both changes. The behavior of OW should be the same like in 4.1 release (OW opens immediately and no progress bar is displayed in the status line). I think we should use 4.1’s behavior, because getting rid of the progress bar in the status line only and leaving new OW behavior there will just confuse the users. Imagine you are building a project, you perform the build action and nothing happens (no OW appears, there is no message, no progress bar to catch your eye, nothing), then you are not sure whether you performed the action or not. So that is why I think that reverting of both changes is necessary.
That is not true. The Ant module has always printed a message to the status line when it starts a process and one when the process ends (for various reasons). I did not remove that status message when implementing issue #58513. Whether the status line message on its own is enough is another question. Please reconfirm what you want to do.
I know about the message in the status line, however I still think we should use 4.1 behavior of OW (OW opens immediately and no progress bar is displayed in the status line).
I suggest that until issue 63586 is fixed, so temporarily now for Beta, we simply change the default value of the option Ant/Always Show Output to true. IMO it is not necessary to revert the code changes, changing the option is enough.
Created attachment 24909 [details] A much less obtrusive indefinite progress component - just shows a rotating icon - may be useful
For me there is a big distinction between the bar that actually show a progress in the form of a percentage and the bar that just show a nervous busy indicator. I like the implementation of the first bar and I do not like the second. In favour for keeping the first bar I would like the design of the second bar differently but still in the bar form, otherwise we'll end up with just another indicator. Maybe the bar's speed may be reduced and it's graphical presentation may be less distinctive (e.g. light gray, a thinner bar). It's function is nothing more than the function of an hour glass cursor. On the other hand I also think more work should be done by the developers who invoke this bar. In some occasions implementations may be provided for a real bar. Sincerely, Patrick Holthuizen
I am Ok with Tonda's suggestion not to do code revert but change the default value of the option Ant/ Always Show Output to true.
To summarize (since you did not do so): 1. Remove (or provisionally disable) the progress indication. 2. Check the option Always Show Output by default. Correct?
I have implemented the requested changes as I understand them. Feel free to open new issues for related problems or requests. By the way, you can pass -J-Dorg.apache.tools.ant.module.run.TargetExecutor.USE_PROGRESS=true to experiment with progress display, but this is off by default. committed * Up-To-Date 1.10 ant/arch/arch-ant-main.xml committed * Up-To-Date 1.31 ant/src/org/apache/tools/ant/module/AntSettings.java committed * Up-To-Date 1.51 ant/src/org/apache/tools/ant/module/run/TargetExecutor.java
Thanks Jesee, you understood changes correctly.
Verified.