On 8-Nov-2013, at 8:37 AM, Paul Elder <pel...@ca.ibm.com> wrote:
> * 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.
_______________________________________________
e4-dev mailing list
e4-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/e4-dev
