Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Now's the time to figure out what we need in e4
Eric/Tom-

Why necessarily restrict the Wizard to a new window (Dialog)?  Like Lars said, a Wizard is a special type of MPartStack which can be displayed in a separate Dialog (most commonly) or in a standard MPart (if you really wanted).  Then when you press buttons like "Next", "Finish", etc. I think it would be more inline with the e4 model to use annotations such as @PerformFinish on the individual wizard pages.  The wizard pages themselves should be an MPart so that it is possible to re-use them as standalone MParts.  While I can't think of a case where I would want to do this off the top of my head, why necessarily restrict the use case.

With all of that said, I still think it would be appropriate to model the Wizard AND WizardPage as model elements.  Even if no additional model functionality is added (which may well be the case), this would allow for instanceof checks.

So a big +1 for:

MDialog (extends MWindow?, ... ?)
MWizard (extends MPartStack, ... ?)
MWizardPage (extends MPart, ... ?)
MPreferencePage (extends MPart, ... ?)

And to touch on the Help System:

Thinking more about this lately; I feel as though this would be a perfect example of how to extend the workbench model.

Tying in with some of the concepts proposed for the IDE Working Group [1], I think the help system, as "fundamental" as it may be could be spun off into a separate project.

That aside, treating the Help System as a separate extension of the workbench model concepts would demonstrate how to add customized model objects and renderers to the workbench.  I could even make the same argument for MWizard, MWizardPage, and MPreferencePage, but MDialog belongs in the actual model.

JD


[1] http://dev.eclipse.org/mhonarc/lists/ide-dev/threads.html#00128



On Thu, Oct 10, 2013 at 1:06 PM, Jonas Helming <jonas.helming@xxxxxxxxxxxxxx> wrote:
Hi,

IMHO, the following bugs would be important:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410787 (Influence the Stylebits of Windows)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=389663 (Merging contributions can lead to duplicate elements in the model)

Cheers

Jonas


Am 10.10.2013 19:49, schrieb Eric Moffatt:

Dirk, there is indeed a struggle between two desires here; on one side we don't want our 'base model' to become overly complex but we do want its concepts to be understandable. Tags as well as the transient and persistent data maps provide a *very* flexible model, to the point that we could handle both 'Dialogs' and 'Wizards' without extending the model at all.

However it's not whether it's possible to do but rather whether our clients (RCP authors...) would gain an advantage from having the new model element types. In this case I see having MDialog and MWizard as deserving of their own model classes because folks writing RCP apps already use these concepts during their design phases.

I'm not as sure whether the WizardPage is needed though even given that it needs to communicate to its container regarding it's 'completeness'. Note that a Dialog also has to communicate with its container to enable the 'OK' button (and show Error Messages?).

Elements in the base model should be at a very high level of abstraction. For me this means MDialog...OK but MTitleAreaDialog, MMessageDialog...not so much. That's not to say that if we identify some common attributes like 'error message' or 'finished' that we shouldn't formalize them in the model, just that we don't want the whole kitchen sink there capable of supporting every possible flavour  of dialog / wizard in existence.

Determining whether something deserves formal existence in the model or not is a fine line and I'd be ecstatic to come out of discussions like this with some sort of guidelines to help future committers understand how to make such choices...might be a good idea for a BOF ?

Eric


Inactive hide details for Dirk Fauth ---10/10/2013 09:38:12 AM---In terms of reusability and the concept of e4, using MPart forDirk Fauth ---10/10/2013 09:38:12 AM---In terms of reusability and the concept of e4, using MPart for wizard pages might be sufficient. Int


    From:

Dirk Fauth <dirk.fauth@xxxxxxxxx>

    To:

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,

    Date:

10/10/2013 09:38 AM

    Subject:

Re: [e4-dev] Now's the time to figure out what we need in e4

    Sent by:

e4-dev-bounces@xxxxxxxxxxx




In terms of reusability and the concept of e4, using MPart for wizard pages might be sufficient. Introducing a new model MWizardPage could lead back to Eclipse 3 if you are not careful.

But I also agree with Tom saying that there might be additional attributes. Looking into WizardPage it is for example necessary to know if the wizard page is complete. But that could also be accomplished by adding new annotations.

Just my two cents ;-)


On Wed, Oct 9, 2013 at 5:22 PM, Lars Vogel <lars.vogel@xxxxxxxxx> wrote:
    > For the model itself how about both MDialog & MWizard extend MWindow (since they show up as windows). Whether or not we also need the MWizard to have a 
    > specific collection of MWizardPages or if we can just have the logic manipulate an MPartStack using ids is open for me, there's are good reasons for either way. The
    > MApplication would be extended to have two new collections; 'dialogs' and 'wizards'.

    I would agree with Wim that MWizardPage might not be necessary. MPart appears at the moment sufficient. I also like the idea of re-using MPartStack for the wizard.




    2013/10/9 Eric Moffatt <emoffatt@xxxxxxxxxx>
      Modeling the Dialogs and Wizards for an application is a good thing to do. If you consider the model to represent the agnostic description of what UI bits the app needs in order to function then it makes perfect sense to say something along the lines of:

      "My Contacts app needs the Contacts window, an Open Contact List dialog and a Create Contact wizard"

      This is a proper indication to anybody wishing to implement that application on *any* platform they they'll need to supply the rendered UI for those components.

      Before getting into the model specifics I'd like to look at what Dialogs and Wizards *are*...

      - They show up in their own windows
      - They both represent requests to gather information from the User
      - They're transient; opened by the IDE -> closed by the User

      So, the specifics of how they're modeled aside, how do the elements communicate the results back to the IDE ? The pattern for creation seems fairly straightforward; add all necessary input parameters into the 'localContext' used to render the Dialog / Wizard. It's less clear how the IDE (app) then retrieves the result.

      For the model itself how about both MDialog & MWizard extend MWindow (since they show up as windows). Whether or not we also need the MWizard to have a specific collection of MWizardPages or if we can just have the logic manipulate an MPartStack using ids is open for me, there's are good reasons for either way. The MApplication would be extended to have two new collections; 'dialogs' and 'wizards'.

      Note that there's a beneficial side-effect of modeling the Dialogs / Wizards; this structure makes it completely natural to embed parts into both Dialogs and Wizard(page)s. One of the initial problems I faced during my demos for this was that I had to 'fake' the embedded part being in the model (see EModelService#hostElement); if the MDialog were modeled this would no longer be an issue.

      Thanks folks, this is exactly the type of discussion I was hoping for,
      Eric


      Inactive hide details for Tom Schindl ---10/09/2013 09:15:51 AM---Not strictly speaking but maybe we need some extra attributesTom Schindl ---10/09/2013 09:15:51 AM---Not strictly speaking but maybe we need some extra attributes later on there so I would model it exp
    From:

Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
    To:

e4-dev@xxxxxxxxxxx,
    Date:

10/09/2013 09:15 AM
    Subject:


Re: [e4-dev] Now's the time to figure out what we need in e4
    Sent by:

e4-dev-bounces@xxxxxxxxxxx
_______________________________________________
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


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


Back to the top