Re: [e4-dev] Model changes for 4.4 M4

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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


Joseph D Carroll Jr ---11/18/2013 06:00:02 PM---I realize these changes are already in master, but I think we are getting too specific with our mode

From:	Joseph D Carroll Jr <jdsalingerjr@xxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:	11/18/2013 06:00 PM
Subject:	Re: [e4-dev] Model changes for 4.4 M4
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

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 <pelder@xxxxxxxxxx> wrote:

Brian de Alwis <briandealwis@xxxxxxxxx> 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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev