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.

Bug 63332 - Unnecessary progress indication when debugger stops at breakpoint
Summary: Unnecessary progress indication when debugger stops at breakpoint
Status: VERIFIED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jindrich Dinga
URL:
Keywords:
Depends on: 43072 63586
Blocks: 58513 87801
  Show dependency tree
 
Reported: 2005-08-30 14:45 UTC by Jiri Skrivanek
Modified: 2006-10-23 18:16 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
A much less obtrusive indefinite progress component - just shows a rotating icon - may be useful (24.74 KB, application/x-compressed)
2005-09-17 10:43 UTC, _ tboudreau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2005-08-30 14:45:45 UTC
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
Comment 1 Jesse Glick 2005-08-31 00:04:06 UTC
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.
Comment 2 Jesse Glick 2005-08-31 00:04:17 UTC
Oops.
Comment 3 Jesse Glick 2005-08-31 00:04:34 UTC
Meant WONTFIX.
Comment 4 Jiri Skrivanek 2005-08-31 10:23:22 UTC
Reassigning to HIE. Please, keep this issue open until this use case is included
in UI specification.
Comment 5 _ lcincura 2005-08-31 13:23:12 UTC
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.
Comment 6 Jesse Glick 2005-08-31 17:24:37 UTC
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.
Comment 7 Jesse Glick 2005-09-01 17:03:23 UTC
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.
Comment 8 Jesse Glick 2005-09-01 17:58:00 UTC
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.
Comment 9 Jindrich Dinga 2005-09-02 16:44:44 UTC
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.
Comment 10 Milos Kleint 2005-09-05 14:28:30 UTC
"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..

Comment 11 Jesse Glick 2005-09-06 19:31:07 UTC
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.)
Comment 12 Antonin Nebuzelsky 2005-09-07 08:50:50 UTC
+1

I like what Jesse suggests in the last comment.
Comment 13 Jesse Glick 2005-09-14 22:55:55 UTC
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.
Comment 14 Milos Kleint 2005-09-15 09:03:43 UTC
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.
Comment 15 Jindrich Dinga 2005-09-15 10:01:40 UTC
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.
Comment 16 Jesse Glick 2005-09-15 19:08:17 UTC
"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?
Comment 17 Jindrich Dinga 2005-09-16 14:27:05 UTC
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.
Comment 18 Jesse Glick 2005-09-16 17:34:18 UTC
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.
Comment 19 Jindrich Dinga 2005-09-17 06:57:10 UTC
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).
Comment 20 Antonin Nebuzelsky 2005-09-17 08:53:55 UTC
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.
Comment 21 _ tboudreau 2005-09-17 10:43:53 UTC
Created attachment 24909 [details]
A much less obtrusive indefinite progress component - just shows a rotating icon - may be useful
Comment 22 pholthuizen 2005-09-17 20:28:04 UTC
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
Comment 23 Jindrich Dinga 2005-09-19 14:27:53 UTC
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.
Comment 24 Jesse Glick 2005-09-19 23:08:23 UTC
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?
Comment 25 Jesse Glick 2005-09-19 23:52:52 UTC
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
Comment 26 Jindrich Dinga 2005-09-20 08:28:52 UTC
Thanks Jesee, you understood changes correctly.
Comment 27 Jiri Skrivanek 2005-10-05 10:42:40 UTC
Verified.