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.
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 wizard.
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
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.
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 ? :-)
Created attachment 22296 [details] unzip to IDE installation
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
> 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.
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. :-(
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).
What is the status of this bug? I think it has been implmented for 5.0, but I'm not sure.
Created attachment 32401 [details] proposed patch
Created attachment 32403 [details] proposed API change
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
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?
Jardo, I have added the covering test this new one iterator. Checking in test/unit/src/org/openide/ProgressInstantiatingIteratorTest.java; /shared/data/ccvs/repository/openide/dialogs/test/unit/src/org/openide/Attic/ProgressInstantiatingIteratorTest.java,v <-- ProgressInstantiatingIteratorTest.java new revision: 1.1.2.1; previous revision: 1.1 done 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
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: http://www.netbeans.org/download/dev/javadoc/org-netbeans-api-progress/org/netbeans/api/progress/ProgressHandleFactory.html#createProgressComponent(org.netbeans.api.progress.ProgressHandle) or thru new method createProgressComponent(handle, boolean showLabel) and make this component react to text that is assigned to the handle via http://www.netbeans.org/download/dev/javadoc/org-netbeans-api-progress/org/netbeans/api/progress/ProgressHandle.html#setDisplayName(java.lang.String) Imho such solution not only makes the wizard api cleaner, but also ensures better consistency between various usages of such handle.
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
Created attachment 32436 [details] proposed change to progress api
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
Integrated in main trunk. Checking in openide/dialogs/test/unit/src/org/openide/ProgressInstantiatingIteratorTest.java; /shared/data/ccvs/repository/openide/dialogs/test/unit/src/org/openide/ProgressInstantiatingIteratorTest.java,v <-- ProgressInstantiatingIteratorTest.java new revision: 1.2; previous revision: 1.1 done Checking in openide/loaders/src/org/openide/loaders/TemplateWizardIteratorWrapper.java; /shared/data/ccvs/repository/openide/loaders/src/org/openide/loaders/TemplateWizardIteratorWrapper.java,v <-- TemplateWizardIteratorWrapper.java new revision: 1.2; previous revision: 1.1 done Checking in openide/loaders/src/org/openide/loaders/TemplateWizard.java; /shared/data/ccvs/repository/openide/loaders/src/org/openide/loaders/TemplateWizard.java,v <-- TemplateWizard.java new revision: 1.22; previous revision: 1.21 done Checking in openide/loaders/src/org/openide/loaders/TemplateWizardIterImpl.java; /shared/data/ccvs/repository/openide/loaders/src/org/openide/loaders/TemplateWizardIterImpl.java,v <-- TemplateWizardIterImpl.java new revision: 1.10; previous revision: 1.9 done Checking in openide/dialogs/nbproject/project.xml; /shared/data/ccvs/repository/openide/dialogs/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done 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 done Checking in openide/dialogs/manifest.mf; /shared/data/ccvs/repository/openide/dialogs/manifest.mf,v <-- manifest.mf new revision: 1.9; previous revision: 1.8 done Checking in openide/dialogs/src/org/openide/Bundle.properties; /shared/data/ccvs/repository/openide/dialogs/src/org/openide/Bundle.properties,v <-- Bundle.properties new revision: 1.7; previous revision: 1.6 done Checking in openide/dialogs/src/org/openide/WizardDescriptor.java; /shared/data/ccvs/repository/openide/dialogs/src/org/openide/WizardDescriptor.java,v <-- WizardDescriptor.java new revision: 1.29; previous revision: 1.28 done Checking in core/windows/src/org/netbeans/core/windows/services/NbPresenter.java; /shared/data/ccvs/repository/core/windows/src/org/netbeans/core/windows/services/NbPresenter.java,v <-- NbPresenter.java new revision: 1.32; previous revision: 1.31 done