* Change MCompositePart to extend MGenericTile<MPartSashContainerElement>
rather than MPartSashContainer. (This is so that MCompositePart will extend
only one concrete type, namely MPart. In implementing split editors/views,
Eric found that the MPart/MPartSashContainer ambiguity caused some problems.)
That makes sense — I had missed the introduction of MGenericTile, and in looking at it I immediately wondered why MCompositePart should assume a part sash.
* Deprecate MInputPart and MInput.
* Question: Is there
need for an 'inputSpec' attribute on MPart? (A replacement for MInput's
inputURI attribute.)
I’ve vacillated on this issue, but I’m in favour of it. It shouldn’t matter once bug 419888 is fixed.
* Create MWizard and MDialog classes
(that extend MWindow), and add corresponding collection attributes on MApplication
* Question
*
Is there need for new attributes on these classes?
*
Is there need for MWizardPage, too? (It seems to me that MWizard's 'children'
being mapped to the wizard's pages is sufficient.)
I’d have thought we wanted MDialog to be distinct from MWindow? And aren’t wizards really a form of dialog?
The Workbench code (currently) assumes that it can take over and manage any MWindow. I don’t think we want the workbench to manage dialogs :-)
Brian.
