JD, this is the reason that we're starting with only the barest of enhancements; we're waiting to see concrete uses before deciding whether or not any other extensions are needed (or indeed if even the new ones are). We realize that we could likely accomplish everything using tags but think that having the model elements available will make it easier for clients to more accurately define their application (and for others to more easily understand what's in the app).
For background there *are* identifiable advantages to incorporating
Dialogs...into the model. Mostly this revolves around allowing the dialog
to hook into the MApplication's context chain (allowing DI & service
access...) as well as normalizing the hosting of MParts in the dialog.
Eric
From: Joseph D Carroll Jr <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 11/18/2013 06:00 PM
Subject: Re: [e4-dev] Model changes for 4.4 M4
Sent by: [email protected]
I realize these changes are already in master, but I think we are getting
too specific with our model. Having an MWizardDialog only opens the door
to having an MWizardPart and IMHO that defeats the entire purpose of having
a generic model in the first place.
If we are going to model the Wizard (which I can make arguments either way)
it should inherit from MPart if anything. I guess I am more for modeling
Wizards AND WizardPages because I feel that makes a better argument for
reuse. But all of this is for naught if we are going to delineate our
model so rigidly.
I would even be for creating a model element that blurs the line between
WizardPage and PreferencePage (call it an MInteractionPage). Because, from
an abstract sense, WizardPage and PreferencePage accomplish the same thing;
taking some form of user interaction. Combine that with the existing DI
framework and there is no need to have separate entities.
So I would vote:
-1 on MWizardDialog
0 on MDialog
I think we can enhance our existing tags on MWindow to accomplish
everything the Dialog does (like even having a "dialog" tag).
JD
On Tue, Nov 12, 2013 at 1:44 PM, Paul Elder <[email protected]> wrote:
Brian de Alwis <[email protected]> wrote on 11/11/2013 12:17:29 PM:
>
> 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 :-)
>
For the first cut, I'm going to create MDialog (subclassing MWindow), and
MWizardDialog subclassing MDialog. If subclassing MWindow proves to be a
problem, we can change it, but logically (at least on the windowing
systems I know of), a dialog is a window.
Paul
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
