In some cases e.g. running, debugging (issue #63332), etc. a project the progress bar is not needed.
Nowadays in progress API, there is no possibility to disable showing the progress bar so in these cases
the progress bar is shown as indefinite which distracts users from working.
Because of this problem we decided to keep same behavior of OW (issue #58513) like in previous
version of NB (than is described in UI spec) until this problem will be solved.
According to the discussion in issue #63332 I'm changing this Enhancement to Defect and also
increasing the priority to P2.
Based on our off-line meeting, I'm changing the type of this issue to TASK.
For background, see my comment in issue #63332 of Sep 6 2005. A method such as
switchToIndefinite() would be ideal from the standpoint of the Ant module. I
guess it would not be very hard to implement.
Is this planned for 5.1? If not, could it be?
I believe Milos and Jindra will agree that we plan this for 5.1. At least
according to the discussion we had a few weeks ago about not doing this for 5.0.
Milos, please, do this API change in trunk soon enough for 5.1. Thanks.
Nothing has happened with this. Will you work on it? Should I work on it?
let me reiterate the requirements as I got a bit lost.
what is needed to handle the case where the application is running through ant
and we don't want to show the irritating indefinite progress bar.
so we want to add a way of telling the progress bar to go into sleep mode.
1. it still needs to show that something is running
2. but it should not attract any attention.
how about a full bar with the text "running" in it?
as far as api changes go, I suggest adding a method markAsLongTerm() that will
switch the UI. any progress called after the markAsLognTerm() method will reset
the bar to whatever it was showing before.
I agree the point here is that we don't want to distract the user with the
indefinite progress bar, but we still want to show indication a task is in progress.
> how about a full bar with the text "running" in it?
The word running could be confusing. This type of progress indication will be
used for compiling, running, debugging and thus the word should be either more
neutral ("in progress"?, something else?) or configurable by the task
("running", "building", "debugging"). Because in some cases we may not be able
to exactly tell what the ant task is doing, we should probably stay with the
Because of some fix in JDK, we do not have blue progress bar, which was moving from the left to the right
side and back, for indefinite tasks in our IDE any more. Nowadays for indefinite tasks we have green
progress bar that is moving in indefinite loop (from left to the right side and again from left to the right
side). Would be possible to slow down this movement a bit? It might not to be so distracting and then we
would switch the progress bar for indefinite tasks.
slowing down is not possible. it's a feature of the look and feel implementation.
1. Correct, something should be visible.
2. ...but there should be no animation.
Method name: switchToQuiescent()? I love that word!
Agreed that changing the appearance or behavior of a JProgressBar is probably
not possible for all L&Fs. In long-term mode, you just should not show a
JProgressBar at all, I guess. Perhaps just show a JLabel with the task's current
Ought to be possible to cancel this long-term mode, using not just progress(...)
methods but also switchTo(...) methods.
Example use case:
1. Users starts Ant process.
2. Progress handle appears in indeterminate mode. (Ant would never use
determinate mode, since it cannot determine what is going to happen!) Display
name is same as OW tab name, probably.
3. As tasks are executed, progress(String) is called with args something like
"Running task: javac"
These would only be visible if you had the process window open, I guess. So
basically you just get an indeterminate JProgressBar.
4. The program is run, i.e. <java>.
5. After a few seconds, nothing new is happening as far as the IDE is concerned,
so it switches to long-term mode. Just "MyProg (run)" is displayed as a static
label in the progress area.
6. If the user opens the processes pop-up window, "MyProg (run)" will appear
with an indeterminate JProgressBar to emphasize that it is still running.
7. Program ends. If anything else happens, progress area switches back to indet.
JPB for a little while, then handle is closed once Ant finishes.
Created attachment 35128 [details]
changes in the progress api module, both api and implementation
Created attachment 35129 [details]
impl changes in the ui module
Created attachment 35131 [details]
the current UI representation of the suspended task..
attached is the suggested API change.
ProgressHandle gets a new method suspend(String) which will put the task's
visual representation into suspended mode. Any later calls to progresshandle
wake up the UI to previous state.
the current impl shows an empty non-moving progress with a supplied text (as
shown on attached picture)
API change without a single test? Could not you write at least simple one?
Looks fine to me.
bar.putClientProperty("sleepy", new Object()); //NIO18N
has a typo; suggest
private static final String KEY_SLEEPY = "sleepy"; // NOI18N
bar.putClientProperty(KEY_SLEEPY, true); // NOI18N
thanks for the review, will integrate shortly.
Same change to AggregateProgressHandle
Checking in src/org/netbeans/api/progress/aggregate/AggregateProgressHandle.java;
/cvs/core/progress/src/org/netbeans/api/progress/aggregate/AggregateProgressHandle.java,v <-- AggregateProgressHandle.java
new revision: 1.10; previous revision: 1.9
Checking in nbproject/project.properties;
/cvs/core/progress/nbproject/project.properties,v <-- project.properties
new revision: 1.14; previous revision: 1.13