Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 58889 - Enhance wizard framework to display progress indication on Finish
Enhance wizard framework to display progress indication on Finish
Product: platform
Classification: Unclassified
Component: Dialogs&Wizards
All All
: P2 (vote)
: 6.x
Assigned To: Jiri Rechtacek
Depends on: 78605
Blocks: 58890 59004 61158 68786 70630 79514
  Show dependency treegraph
Reported: 2005-05-13 18:10 UTC by Antonin Nebuzelsky
Modified: 2008-12-22 16:01 UTC (History)
9 users (show)

See Also:
Issue Type: TASK

unzip to IDE installation (1.47 MB, application/octet-stream)
2005-05-25 08:22 UTC, Jiri Rechtacek
proposed patch (9.79 KB, patch)
2006-08-01 11:15 UTC, Jiri Rechtacek
Details | Diff
proposed API change (2.09 KB, patch)
2006-08-01 12:06 UTC, Jiri Rechtacek
Details | Diff
proposed change to progress api (21.81 KB, patch)
2006-08-02 11:39 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2005-05-13 18:10:42 UTC
Wizard framework should be ideally extended to be able to display progress
indication component on the last page of the wizard and indicate the progress of
the action in it after Finish of the wizard is pressed.

This will require an idea how the activities currently invoked via listeners
could be bound more tightly with the wizard and provide its progress back to the
Comment 1 Jiri Rechtacek 2005-05-24 15:44:17 UTC
Eval: What part of wizard framework could be changed to use Progress API?

- in general the WD.Panel is responsible for a user feedback, it knows how long
the method WD.P.isValid() and WD.P.storeSettings() works, could implement
Progress into itself. IMHO the framework cannot help here.

- if WD.P is instance of WD.ValidatingPanel then panel has the method validate()
which has been designed for long-term operation. Maybe a candidate for progress
support but this interface is not widely used in Netbeans. The panel author can
use ProgressAPI if needed. So, no support planned for now.

- if WD.Iterator instance of InstantiatingIterator: the case of NewProject and
NewFile actions. It's really candidate to use Progress API.
How the WD.II works? It work in two phases: the at first calls the method
WD.II.instantiate() on click of Finish button, say Phase I.
At the end of instantiate() method the wizard is closed and returns the flow
control back to caller. e.g. NewProject/File action. These actions obtain a set
of new objects and perform other operation on these objects, i.e. opening
project in GUI, selecting object in view etc. Let's say Phase II.
Phase I.
- the wizard remains open during the phase I. runs,
- is invoked in EQ but it's not enforced, could be replaned out AWT queue,
- users are notified by wait cursor,
- working this phase depends on iterator's author, may varies an case by case.
Phase II.
- wizard is already closed,
- most of work is SW.invokeLater(),
- working not depend, it's constantly,
- users also notified by a wait cursor.

What I propose? WD should display the progress bar when Phase I. runs
(optionally can WD.II.instantiate() post to another task if needed). When the
wizard is closed (Phase II. runs) then the wait cursor is enough, no change.

Any comments, recommendations? Thanks
Comment 2 Jan Chalupa 2005-05-24 17:46:33 UTC
I think it really depends on how long the Phase I and Phase II generally take
and what is the proportion between those two. For example, showing a progress in
the wizard for Phase I if it takes less than a second and then get a wait cursor
for additional 5+ seconds in Phase II probably wouldn't provide the best user
experience. On the other hand, if Phase I takes longer and Phase II takes just a
second or two, your proposal would probably work fine.
Comment 3 Jiri Rechtacek 2005-05-24 22:38:51 UTC
Yes, I'll provide a debug build which displays timestamps on the start/end both
phases, possible try couple types of project types and new files.
I tried run Phase I. in a task out AWT it worked for me, seems as doable for me.
Maybe silly question: isn't weird that Openide Dialogs API will depend on
Progress API ? :-)
Comment 4 Jiri Rechtacek 2005-05-25 08:22:43 UTC
Created attachment 22296 [details]
unzip to IDE installation
Comment 5 Jiri Rechtacek 2005-05-25 08:39:37 UTC
I attched zip with more verbose openide/dialogs/WizardDescriptor and
projects/ui/NewProject|File. This reports length of time for both phases.
First notion: New Java Application Project P.I (3'600ms), P.II(630ms)
New Blue Print - Client Side Validation Project P.I (26'800ms), P.II(3'800ms -
broken references!)
New Java File P.I (270ms) P.II (180ms)
New XML Catalog P.I (130ms) P.II (20ms)

Sorry, my mistake the verbose write NewProject in console for both case
NewProject and NewFile too :-(

Tondo, please try consider suitability my proposal. Thanks
Comment 6 Antonin Nebuzelsky 2005-05-25 08:47:09 UTC
> Tondo, please try consider suitability my proposal.

I did not run the build with statistics myself yet, but given the numbers you
write here for Ph.I. and Ph.II I think the proposal is very reasonable. The
phase II could be IMO covered with the hour-glass cursor because it seems to
take signigicantly less time than phase I.
Comment 7 Antonin Nebuzelsky 2005-06-08 14:43:35 UTC
Hm, finally I tried your stats, but got completely opposite results:
Create Anagram project: PhI 282ms, PhII 1043ms
Create TomcatServletExample project: PhI 289ms, PhII 4072ms
Create J2eeClientForDocOrientedServices project: PhI 189ms, PhII 3726ms

Given these numbers I don't see the solution covering only the PhI with progress
bar as suitable. :-(
Comment 8 Martin Grebac 2005-09-08 16:53:53 UTC
Is there (or will there be in 5.0 timeframe) anything new with this task? It's
quite a problem for j2ee and websvc wizards. If not, we'll probably revert back
from the new progress api to the old code we had (at least for websvc).
Comment 9 Marian Mirilovic 2005-12-22 12:52:05 UTC
What is the status of this bug? I think it has been implmented for 5.0, but I'm
not sure.
Comment 10 Jiri Rechtacek 2006-08-01 11:15:09 UTC
Created attachment 32401 [details]
proposed patch
Comment 11 Jiri Rechtacek 2006-08-01 12:06:06 UTC
Created attachment 32403 [details]
proposed API change
Comment 12 Jiri Rechtacek 2006-08-01 12:20:52 UTC
I want to introduce new one interface ProgressInstantiatingIterator.
public interface ProgressInstantiatingIterator extends
AsynchronousInstantiatingIterator {
 public Set <Object> instantiate (ProgressHandle handle) throws IOException;
 public JLabel getProgressLabel ();

If a interator implements this interface then wizard frameword notifies users
while instantiate is running by a progress bar, this progress bar is integrated
into wizard panel. Instantiating of newly created objects is invoked asynchronously.

If a interator implements AsynchronousInstantiatingIterator interface then
wizard frameword supplies a progress bar in nndeterminate mode.

See the attached patchs and UI spec. I'm going to integrate this improvement in
NB6.0/M2. Thanks
Comment 13 Jaroslav Tulach 2006-08-01 13:32:13 UTC
Y01 I do not understand why there is a method returning JLabel. Imho if it has 
to be there, it should return a String.

Y02 No test for ProgressInstantiatingIterator, there should be at least the 
same test(s) as for AsynchronousInstantiatingIterator as externally they 
behave similary, are they not?
Comment 14 Jiri Rechtacek 2006-08-01 19:02:07 UTC
Jardo, I have added the covering test this new one iterator.
Checking in test/unit/src/org/openide/;
new revision:; previous revision: 1.1

As to the method getProgressLabel(), I basically don't like this method, I'm
afraid of less benefit to API users. I designed JLabel as return parameter
because more chances of add a icon or whatever but I have no problem to return a
string I agree it looks better. Thanks
Comment 15 Jaroslav Tulach 2006-08-02 08:29:59 UTC
Returning string from the component description is better, but still not nice. 
Imho this beats the whole purpose of Progress API, which aimed to standardize 
how people do handle progress. In my opinion we shall instead enhance the 
progress API to create a JComponent with label, either thru:
or thru new method createProgressComponent(handle, boolean showLabel)
and make this component react to text that is assigned to the handle via

Imho such solution not only makes the wizard api cleaner, but also ensures 
better consistency between various usages of such handle.
Comment 16 Milos Kleint 2006-08-02 11:37:50 UTC
proposed API change for progress that allows to externalize the label components
to show detail messages or the tasks' display name in custom UI. Should help to
streamline the wizard's api.

attaching patch
Comment 17 Milos Kleint 2006-08-02 11:39:00 UTC
Created attachment 32436 [details]
proposed change to progress api
Comment 18 Jiri Rechtacek 2006-08-04 12:56:17 UTC
Thanks all to review and done resulting changes of Progress API. I'll respect
recommended changes and will integrate it in main trunk ASAP. Thanks
Comment 19 Jiri Rechtacek 2006-08-06 16:59:36 UTC
Integrated in main trunk.

Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.2; previous revision: 1.1
Checking in openide/loaders/src/org/openide/loaders/;
new revision: 1.22; previous revision: 1.21
Checking in openide/loaders/src/org/openide/loaders/;
new revision: 1.10; previous revision: 1.9
Checking in openide/dialogs/nbproject/project.xml;
/shared/data/ccvs/repository/openide/dialogs/nbproject/project.xml,v  <-- 
new revision: 1.7; previous revision: 1.6
Checking in openide/dialogs/apichanges.xml;
/shared/data/ccvs/repository/openide/dialogs/apichanges.xml,v  <--  apichanges.xml
new revision: 1.8; previous revision: 1.7
Checking in openide/dialogs/;
/shared/data/ccvs/repository/openide/dialogs/,v  <--
new revision: 1.9; previous revision: 1.8
Checking in openide/dialogs/src/org/openide/;
new revision: 1.7; previous revision: 1.6
Checking in openide/dialogs/src/org/openide/;
new revision: 1.29; previous revision: 1.28
Checking in core/windows/src/org/netbeans/core/windows/services/;
new revision: 1.32; previous revision: 1.31

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo