Community
Participate
Working Groups
It would be highly useful if CheatSheets (and other Eclipse facilities) could exercise more programmatic control over Wizards. In particular it would be nice to have API's allowing one to: 1) provide default values for all values gathered by the Wizard 2) receive notification of changes to any values gathered by the Wizard 3) take exactly the action the Wizard would have cause to occur without invoking the Wizard (note, clearly the information the Wizard would have gathered from the user must be provided).
Adding Dejan as he owns the cheatsheets. Some interesting ideas here but they are enough work that we would have to make it a full plan item. Please feel free to contribute any suggested API or patches to this report.
My original (very sketchy) thoughts were that you wanted to have a WizardContext class to provide the backing store for your wizard that is essentially a Map, with "org.eclipse.foo.myproperty" like keys. Glancing about it looks like it may be possible to abuse the Preference related classes here. You'd like to be able to attach an observer to the whole WizardContext, and also to individual properties of the WizardContext. WizardContext's would need methods to support merging: WizardContext.merge(WizardContext contrib,boolean override). WizardContext would copy the properties from contrib into the calling WizardContext. If override is true it would overwrite existing properties of the same name, if false, it would not overwrite properties of the same name. Changes to the API of Wizard (or some appropriate subclass thereof) would be to add Wizard(... ,WizardContext) - a constructor which allows passing in a WizardContext for the Wizard. Wizard.getWizardContext() - accessor Wizard.contributeWizardContext(WizarcContext contrib) - merge with override contrib into the existing WizardContext of the Wizard. Since Wizards are primarily composed of WizardPages (as near as I've been able to tell thus far) each WizardPage, at the time it is added to a Wizard, would need to: 1) Define a WizardContext of it's intrinsic defaults. 2) Get the WizardContext of it's containing Wizard. 3) Merge it's intrinsic defaults without override into the WizardContext for the Wizard. 4) Use the Wizard's WizardContext as backing store for data it collects. It would probably also be of utility to give WizardPage methods: getWizardContext() - to return the WizardContext it is using getDefaultWizardContext() - to return it's intrinsic default WizardContext The Wizard class ( or some appropriate subclass) would need to provide facilities for observing page changes and cancel/finish by outside parties. When chaining Wizards (as NewWizard does) the WizardContext would be passed on to the next Wizard in the chain. You probably want to create (and my thoughts get really fuzzy here) a WizardAction which can be subclassed for each Wizard to perform the action the Wizard needs to perform. WizardAction is passed the final WizardContext from the Wizard on finish and does whatever it needs to do. This way if I have some point (menu item, cheatsheet action, etc) where I would like to do something for which I would normally invoke a Wizard, but don't want to invoke that Wizard I can. I also seem to have a deeply seated desire (for which I can't yet provide a reasonable explanation) to break off the validation process for WizardContexts into children of a WizardValidator class. I mention this only in passing as it's still to fuzzy in my mind. This is still extremely rough in general, and in particular around Wizard chaining and which events should be observable in the Wizard class. I throw it out only for sake of discussion to sort of show the direction of my thinking.
Thanks for your input Ed. BTW our priorities need to be set by so that we can plan upcoming releases so please don't change then\m.
My apology, I indavertently changed the priority when I changed the severity, I'm changing it back now.
I think it would be better if we solve this problem as part of the larger UI Automation effort. For example, there is no reason why the same cannot be done for Preferences, or Search, or any other standard dialog in Eclipse. From the client point of view, active help actions would also benefit from this capability, as would intro commands.
Yes! Overall GUI automatability would be fantastic. Of particular utility would be if the user could be guided through taking GUI actions themselves by in context annotations. Picture a popup pointing to the "File" menu item that says "Select the File Menu", which goes away when the user selects the "File" menu and is replaced by a popup pointing to the "New" menu selection saying "Select New", and so on... guiding a user through GUI interaction. Thoughts?
Prakash is now responsible for watching bugs in the [Wizards] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
