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 63586 - Provide possibility to not show the progress bar
Summary: Provide possibility to not show the progress bar
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Progress (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords: API, API_REVIEW_FAST, UI
Depends on:
Blocks: 63332 70630 83313 87801
  Show dependency tree
 
Reported: 2005-09-02 16:47 UTC by Jindrich Dinga
Modified: 2008-12-22 11:59 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
changes in the progress api module, both api and implementation (9.84 KB, patch)
2006-10-12 10:05 UTC, Milos Kleint
Details | Diff
impl changes in the ui module (4.81 KB, patch)
2006-10-12 10:05 UTC, Milos Kleint
Details | Diff
the current UI representation of the suspended task.. (260.02 KB, image/tiff)
2006-10-12 10:20 UTC, Milos Kleint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jindrich Dinga 2005-09-02 16:47:40 UTC
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.
Comment 1 Jindrich Dinga 2005-09-15 13:29:30 UTC
According to the discussion in issue #63332 I'm changing this Enhancement to Defect and also 
increasing the priority to P2.
Comment 2 Jindrich Dinga 2005-10-10 16:06:17 UTC
Based on our off-line meeting, I'm changing the type of this issue to TASK.
Comment 3 Jesse Glick 2005-12-02 22:10:31 UTC
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.
Comment 4 Jesse Glick 2005-12-13 02:14:58 UTC
Is this planned for 5.1? If not, could it be?
Comment 5 Antonin Nebuzelsky 2005-12-13 09:34:50 UTC
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.
Comment 6 Jesse Glick 2006-08-08 17:36:23 UTC
Nothing has happened with this. Will you work on it? Should I work on it?
Comment 7 Milos Kleint 2006-08-09 07:36:52 UTC
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.


Comment 8 Antonin Nebuzelsky 2006-08-09 09:01:12 UTC
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
neutral option.
Comment 9 Jindrich Dinga 2006-08-09 09:48:17 UTC
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.
Comment 10 Milos Kleint 2006-08-09 09:50:52 UTC
slowing down is not possible. it's a feature of the look and feel implementation.
Comment 11 Jesse Glick 2006-08-09 16:29:59 UTC
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
displayName?

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.

Reasonable?
Comment 12 Milos Kleint 2006-10-12 10:05:11 UTC
Created attachment 35128 [details]
changes in the progress api module, both api and implementation
Comment 13 Milos Kleint 2006-10-12 10:05:44 UTC
Created attachment 35129 [details]
impl changes in the ui module
Comment 14 Milos Kleint 2006-10-12 10:20:45 UTC
Created attachment 35131 [details]
the current UI representation of the suspended task..
Comment 15 Milos Kleint 2006-10-12 10:26:48 UTC
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)

please review.



Comment 16 Jaroslav Tulach 2006-10-12 12:51:01 UTC
API change without a single test? Could not you write at least simple one?
Comment 17 Jesse Glick 2006-10-19 23:13:29 UTC
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
Comment 18 Milos Kleint 2006-10-23 10:07:10 UTC
thanks for the review, will integrate shortly.
Comment 19 Milos Kleint 2006-10-23 12:32:59 UTC
done.
Comment 20 Milos Kleint 2007-08-20 14:21:51 UTC
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
done
Checking in nbproject/project.properties;
/cvs/core/progress/nbproject/project.properties,v  <--  project.properties
new revision: 1.14; previous revision: 1.13