Community
Participate
Working Groups
We should think if we should discuss the integration of Wizards/Dialogs into our Application Model which could e.g. help with KeyBindings in there, ... .
Tom, how do you see this working? How deep would you expect this model to go (all the way through SWT widgets or something at a higher level)?
I'd see this at a very very highlevel: Dialog 1 Part Wizard 1 .. n Part but I really haven't thought about it in detail but when it is part of the model we could assign keybindings, ... to it.
Would we model *all* dialogs (e.g., MessageBox.openConfirm()), or just higher-level dialogs? Would we try to capture trays? We might want to allow dialogs to have trim, toolbars, and perspectives (e.g., like many MacOS X preference dialogs).
(In reply to comment #3) > Would we model *all* dialogs (e.g., MessageBox.openConfirm()), or just > higher-level dialogs? Would we try to capture trays? Only highlevel dialogs. I think about the various WizardDialogs we currently have. > > We might want to allow dialogs to have trim, toolbars, and perspectives (e.g., > like many MacOS X preference dialogs). Well then they are Workbench Windows not?
(In reply to comment #4) > (In reply to comment #3) > > We might want to allow dialogs to have trim, toolbars, and perspectives (e.g., > > like many MacOS X preference dialogs). > > Well then they are Workbench Windows not? Good point. "Dialog" typically implies some kind of modal behaviour, so you're right, those preference dialogs are really windows.
We can already demo that you can put parts into wizards by creating a local context and calling createGui directly. I'm hoping that the various Commands infrastructure discussions will produce a better way to manage the key bindings problems but I can see where having the ability to define the bindings for such a part might be quite useful. I'm less clear as to whether modeling the high-level dialogs will help very much versus ensuring that the key bindings story is open enough to allow KB's in a dialog... Miscellaneous observations: - any part used in a dialog/wizard *must* be multi-instance and cannot be shared (if not then the only choice for the dialog is to 'kidnap' the part from the main ui layout, leaving a hole where it was) - Parenting the dialog's context is important...this is a KB issue in the sense that do we always want to use the current context as the basis (i.e. Debug Perspective) and use its ActionSet info...or could we make a particular wizard's context be based on a particular perspective (i.e. perhaps the Create Class wizard should always use the Java Perspective's KB set regardless of the currently active perspective)?
I'll remove this from the 4.1 model evolution - I still think having highlevel dialogs/wizards in the model is benefitial but it needs more time to make up the design
*** This bug has been marked as a duplicate of bug 421462 ***
