Bugzilla – Full Text Bug Listing
| Summary: | [Wizards] [JFace] Method to finsish&close wizard programmatically | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mathias Schaeffner <mathias.schaeffner> | ||||
| Component: | UI | Assignee: | Boris Bokowski <bokowski> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | d.nachev, heiko.boettger, Kevin_McGuire, Michael.Valenta, prakash, remy.suen | ||||
| Version: | 3.4.1 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Mathias Schaeffner
(In reply to comment #0) > Possible solution discussed here: > http://www.eclipse.org/newsportal/article.php?id=43562&group=eclipse.platform.swt#43562 So I presume you'd like a method that's exposed at the IWizard level that closes the WizardDialog? There is no guarantee that the container is a WizardDialog though as you could theoretically embed wizards in a workbench part or any arbitrary Composite. I haven't put much thought in the design of this API, but it is apparent that the use case described in the newsgroup thread is hard to be accomplished, because there is easy way to finish the wizard (IWizard.performFinish()), but there is no way to close the wizard container (in case it is a dialog). Because of the wizard concept, when IWizard.performFinish() is executed, there is always some kind of IWizardContainer recycling following: in case of dialog, the dialog is closed, in case of workbench part will either be hid or the wizard will be restarted. It is up to the IWizardContainer implementation to handle this operation in an appropriate way including ignoring the operation. And the most important: I suggest the following method is added to IWizardContainer: public void finish(); (In reply to comment #3) > And the most important: I suggest the following method is added to > IWizardContainer: > > public void finish(); > what does the finish() method has to do with the wizardContainer? It is logical to ask the wizard to finish, but why would we ask the wizardContainer to finish() I don't think it makes a neat api. I would also really like a method like public void finish(); in IWizardContainer. I know that there is no guarantee that the container is a WizardDialog. Actually I use the platform extension point org.eclipse.ui.newWizards, so I'm not involved in creating the container, just getting the wizard back. Operating on the wizard level I can only call getContainer() to get access to it. But that doesn't help, if I call finish() on wizard level. There is need for a method (certainly in IWizardContainer) that closes/dispose the container, whatever the container implementation really is. In case of a WizardDialog, it should be closed like a normal Dialog. Is there are a case, where performFinish() isn't followed by some action from the IWizardContainer? No, the wizard metaphore requires that after the wizard is finished (performFinish() is executed), the container needs to dispose itself or restart or go in some starting position, but there is never a case where the container will just sit there and wait for additional input from the user. What should IWizardContainer do, if IWizard.performFinish() is executed successfully? Usually, the performFinish() method is called by the IWizardContainer and the wizard container knows what to do. In case, however, that someone else drives the wizard (in the concrete case this is the wizard page itself, which handles double clicking in a tree or in a list), the wizard can be easily finished (with performFinish()), but the container isn't aware of this and will sit and do nothing, which I think is not a correct response. If we have IWizardContainer.finish() method, we someone else can drive the wizard. After a bit of a thought, I suggest that IWizardContainer.finish() should call IWizard.performFinish(). The reasoning behind this is as follows: IWizard defines wizard logic and structure (what pages the wizard contains, how are the pages organized, how they behave, etc.), while IWizardContainer uses this information to present and drive the wizard (show particular page, advance to the next page, go back the page, finish the wizard, etc.). We have the methods to switch between pages, what we lack is way to finish the wizard and to cancel (IWizardContainer.cancel()) the wizard. What do you think? Does it sound more reasonable now? How about you attach a patch so that we can discuss a concrete proposal? See http://wiki.eclipse.org/Platform_UI/How_to_Contribute I'll try to provide a patch, but I'm little overwhelmed, that's why I still try to explain my idea in text form:) Created attachment 122652 [details]
initial proposal for new IWizardContainer API
Here is an initial proposal for the new API. Let's discuss it.
Kevin: Danail is proposing new API for wizard dialogs that would allow a wizard page to trigger the wizard dialog's cancel or finish functionality. The proposed API makes sense at the pure technical level, but I am concerned about the resulting user experience. Could you have a look at this and comment? Thanks! (In reply to comment #10) > Kevin: Danail is proposing new API for wizard dialogs that would allow a wizard > page to trigger the wizard dialog's cancel or finish functionality. The > proposed API makes sense at the pure technical level, but I am concerned about > the resulting user experience. Could you have a look at this and comment? I'd like to understand the motivating cases of why we want to programmatically finish and close the wizard without the user hitting the Finish button. Cancel I'd understand, but not Finish. (In reply to comment #11) > (In reply to comment #10) > > Kevin: Danail is proposing new API for wizard dialogs that would allow a wizard > > page to trigger the wizard dialog's cancel or finish functionality. The > > proposed API makes sense at the pure technical level, but I am concerned about > > the resulting user experience. Could you have a look at this and comment? > > I'd like to understand the motivating cases of why we want to programmatically > finish and close the wizard without the user hitting the Finish button. Cancel > I'd understand, but not Finish. > Simple example, why I opened this bug. In the New Project Wizard you can select a project type, but when you do a double click it automatically jumps to the next wizard page. In my case there is such a list in the last wizard page. So it would be convenient if the user can do a double click there as well. But obviously there is no next page after the last page, so it would be nice if I can finish the wizard. (programmatically throu the double click listener). (In reply to comment #12) > Simple example, why I opened this bug. > > In the New Project Wizard you can select a project type, > but when you do a double click it automatically jumps to the next wizard page. > > In my case there is such a list in the last wizard page. > So it would be convenient if the user can do a double click there as well. > But obviously there is no next page after the last page, so it would be nice if > I can finish the wizard. (programmatically throu the double click listener). Thanks for the explanation. I'm not sure I've seen a wizard behave in this way (not just an Eclipse wizard). Have you seen examples in commercial products? Or citation in say Mac or Windows style guides? I think I'd find the behaviour surprising: 1) Double click usually == "open" which for wizards can reasonably mean "next page". Using it as Finish adds a new meaning *only* if you're on the last page. 2) Wizards have a clear edit/commit style to them which allows to you be sure that the values are what you want prior to commit (Finish). Thus it's good if Finish is an explicit action, not an implicit one like double click. 3) The recommended fast way out of a wizard is for keyboard focus to be in the list but for the Finish button to be active so that <return> triggers it. One way it can fail is user doesn't realize they are on last page, they double click, either to advance page or by accident, and poof wizard is gone. What happened? What values did I just use? This is a problem if the operation isn't easily undone (e.g. server value change). Thus I believe that this particular use of double-click would actually introduce usability issues and I'd recommend against it. Kevin, really good point, I must admit. But still, in my case it's kind of strange. I've got 4 wizard pages showing lists where the user has to make a selection. On 3 of them there is a double click listener applied. But not on the last page. Actually while using the wizard I got annoyed myself that I have to use the finish button explicitly. Double click is just so convenient on first 3 pages. But I think I'll keep it this way, because your explanation makes lots of sense, thanks. Thanks Kevin! (In reply to comment #14) > Kevin, really good point, I must admit. > > But still, in my case it's kind of strange. > I've got 4 wizard pages showing lists where the user has to make a selection. > On 3 of them there is a double click listener applied. > But not on the last page. > > Actually while using the wizard I got annoyed myself that I have to use the > finish button explicitly. Double click is just so convenient on first 3 pages. > > But I think I'll keep it this way, because your explanation makes lots of > sense, thanks. I understand the desire for efficiency, especially if you did the same action three times through the wizard. All I can recommend is to make <return> your friend, as it provides easy keyboard only completion with all the right feedback and expectation. It was a good discussion though! *** Bug 72211 has been marked as a duplicate of this bug. *** |