Community
Participate
Working Groups
a) Make MDialog a subclass of MElementContainer it makes no sense to inherit the mainMenu stuff from MWindow, if you want something with a menu create an MWindow b) Add a mew marker class MDialogElement who extends MApplicationElement which is implemented by MPart, MCompositePart, MStack and MSashContainer c) Make MWizard a subclass of MElementContainer - the reason not inherting from MDialog is that I only want to allow very specific elements d) Add a new marker class MWizardElement who extends MUILabel and is implemented by MPart and MCompositePart
This is a very good initiative to take this problem Tom ! I will try to help
Sounds good and AFAIK we did not release MDialog and MWizard as API
Tom, Lars, Wim, Jonas, and all the others E4 committers, ... if you attend Econ NA, wouldn't it be great to meet us about this major issue and to definitively fix the application model ?
New Gerrit change created: https://git.eclipse.org/r/45212 WARNING: this patchset contains 1846 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Before going forward I'd like to know if I will get PMC approval for the following changes: * (provisional) MFrame introduced as base class for MWizard & MDialog * (provisional) MWizard will change to inherit from MFrame * (provisional) MDialog will change to inherit from MFrame * (provisional) MDialogElement introduced * (provisional) MWizardElement introduced * (API change) MPart, MPartStack and MPartSashContainer will get the MDialogElement & MWizardElement as markers (this will NOT add methods, ... because they inherit the base interfaces already through other means) * (API change) MApplication will get a new "List<MWizard> wizards" Dani would you accept such a change? I guess the most critical part is the inheritance changes from MPart, MPartStack, MPartSashContainer - I guess I could live without them and breaking adopters of this new provisional API in Mars+1 but the better solution would be if you would allow me to introduce those changes as well. Don't look at the gerrit-commit we first need to fix the bug 463879 so that the changes introduced get more obvious.
Tom, Just a question. If the MWizard is the same concept than the JFace wizard (containing wizard pages), it is strange to bind it to a MFrame ? There should be a MWizardDialog class which is a specific MDialog and which can display a MWizard ? In this case the MWizard would be a model containing different pages but with no link to dialog... There could be the same idea for the preference pages, which could be described in the model (with hierarchy and owned at the top level of application), and a helper class MPreferenceDialog would display them... And the same for properties...
Our model is an abstraction of the real world (and not JFace) - I have found the differing between WizardDialog and Wizard always strange. The only change you can convince me at the moment is to name MWizard -> MWizardDialog and MWizardElement -> MWizardPage.
New Gerrit change created: https://git.eclipse.org/r/45218
so the new change set makes a lot more sense!
Yes I know that the model must not contain JFace consideration and must be UI agnostic. If you add the MWizardDialog as you said why don't you add the MPreferenceDialog ? Why wizard are included in the model and not other concepts ? Is it scheduled for later ? We could have an application described with this hierarchy : MApplication ... Handlers... Commands... WizardDialogs MyWizard1 WizardPage1 WizardPage2 AnotherWizard WizardPage Preferences(Dialogs) General PrefPage PrefPage2 Java Code Formatter... Another question... in the current application model we have 'Windows and Dialogs'. Should the wizardDialog be owned by windows or by application ? Why dialogs are owned by window today ? Is it only for runtime consideration so as to deal with the modal state ?
[...] > Another question... in the current application model we have 'Windows and > Dialogs'. Should the wizardDialog be owned by windows or by application ? > Why dialogs are owned by window today ? Is it only for runtime consideration > so as to deal with the modal state ? This is a problem in the tooling - at the model-level a window only has child windows! I guess for the start it is enough to have dialogs at the top-level but in future it might make sense to have them also at Window, Perspective and even Part level.
(In reply to Thomas Schindl from comment #11) > [...] > > > Another question... in the current application model we have 'Windows and > > Dialogs'. Should the wizardDialog be owned by windows or by application ? > > Why dialogs are owned by window today ? Is it only for runtime consideration > > so as to deal with the modal state ? > > This is a problem in the tooling - at the model-level a window only has > child windows! > > I guess for the start it is enough to have dialogs at the top-level but in > future it might make sense to have them also at Window, Perspective and even > Part level. Rethinking this I think we should add them now already as well, until Dani did not answer my general question I can not really proceed though.
> MApplication > ... > Handlers... > Commands... > WizardDialogs > MyWizard1 > WizardPage1 > WizardPage2 > AnotherWizard > WizardPage > Preferences(Dialogs) > General > PrefPage > PrefPage2 > Java > Code Formatter... > > Your Preference Dialog is nothing more than: MDialog<MPerferenceContainer<MPreferencePage>>
If dialog is generic but it is not the case.. And for wizard, we could also have : MDialog<MWizard<MWizardPage>> ... :) if MWizard is a wizard description and not a dialog... So we will wait for the dani's remarks...
Olivier I've uploaded a new patchset which i think addresses your concerns and does not require marker interfaces to be implemented by current APIs: * (provisional) MFrame extends ElementContainer<Frame> * (provisional) MFrameElement extends UIElement marker interface to restrict content * (provisional) MDialog extends MUILabel, MGenericTile<MPartSashContainer>, MFrameElement to model a simple dialog content including all the buttons like OK, CANCEL, ... * (provisional) MWizard extends MUILabel, MGenericStack<MStackElement>, MFrameElement to model a wizard with pages where the MStackElement is the page * modified (provisional) API MApplication#dialogs: List<Frame<FrameElement>> * new (provisional) API MWindow#dialogs: List<Frame<FrameElement>> * new (provisional) API MPerspective#dialogs: List<Frame<FrameElement>> * new (provisional) API MPart#dialogs: List<Frame<FrameElement>> Dani can you cast your vote if: a) the modification of MApplication#dialogs is OK b) the new provisional APIs on MWindow, MPerspective and MPart are OK The only possible client breakage is MApplication#dialogs but this stuff is: a) provisional b) does not work at all so its highly unlikely that someone used it
Sorry posted the wrong summary: Olivier I've uploaded a new patchset which i think addresses your concerns and does not require marker interfaces to be implemented by current APIs: * (provisional) MFrame extends ElementContainer<Frame> * (provisional) MFrameElement extends UIElement marker interface to restrict content * modified (provisional) API MDialog extends MUILabel, MGenericTile<MPartSashContainer>, MFrameElement to model a simple dialog content including all the buttons like OK, CANCEL, ... * modified (provisional) API MWizard extends MUILabel, MGenericStack<MStackElement>, MFrameElement to model a wizard with pages where the MStackElement is the page * modified (provisional) API MApplication#dialogs: List<Frame<FrameElement>> * new (provisional) API MWindow#dialogs: List<Frame<FrameElement>> * new (provisional) API MPerspective#dialogs: List<Frame<FrameElement>> * new (provisional) API MPart#dialogs: List<Frame<FrameElement>> Dani can you cast your vote if: a) the modification of currently provisional API is OK b) the new provisional APIs on MWindow, MPerspective and MPart are OK As far I can see the current MDialog / MWizard stuff does not work at all reliable so I think we can safely modify it - we anyways marked this all as provisional.
I would prefer if we do this work after the Eclipse 4.5 release, doining model changes in the API freeze period feels wrong.
First of all i agree it is late but: - the API freeze is to allow downstream projects to adapt to none provisional API new in the release - the current (provisional) API is totally dysfunctional = not working and just plain wrong - we break no API and only add new provisional API - the main audience for the API are RCP devs and to collect feedback we most of the need to ship provisional stuff in a release we never got enough feedback for milestones if the Consumer have not been the platform itself or jdt
(In reply to Thomas Schindl from comment #16) > Sorry posted the wrong summary: > > Olivier I've uploaded a new patchset which i think addresses your concerns > and does not require marker interfaces to be implemented by current APIs: This looks nice and abstract to me. I can't imagine anyone using the MDialog and MWizard elements because they are awkward to use. I found that out when I implemented them in the model editor. I would not think that using these abstract dialogs outside MApplication would be used a lot. However, I can imagine local preferences to be modeled like this. So there must be other use cases as well. You mentioned "Model != JFace". While this is true, would the general practice not be to just use JFace implementations of Wizards, Dialogs and Preferences outside the model? Or do you maybe envision a JFace-II that works from the model? I agree with the apparent strange connection between WizardDialog and Wizard but the WizardDialog sets the while train in motion. We miss that in the model, how do you envision that the wizard pages are traversed? * Must everybody implement one themselves? * MFrame implementations that Eclipse provides OOTB (MJFace or JFace-II)? How would one want to use Dialogs and Wizards IRL? In the case of MDialog it was to be done something like this: @Inject public void createControl(MDialog pDialog){ pDialog).setToBeRendered(true); // No API. Quite useless. } Should it be more like: @Inject public void createControl(MyMFrameDialog pDialog){ pDialog.open(); } *** OR *** @Inject public void createControl(MPart pPart){ pPart.getFrame("MyNewWizard").open(); }
(In reply to Lars Vogel from comment #17) > I would prefer if we do this work after the Eclipse 4.5 release. I agree. I would like to discuss some use cases and forthcoming API on how the user should operate these things.
Samples and specification would be welcome : - How will we create a wizard -> where should it be defined in the application model and how should we write the corresponding pojo (jface or javafx or whatever ) ? - How will we create a preference page -> same questions ? - How will we create a property page -> same questions ? And would it be still handled in the model ? - What is the goal of dialogs ? Is it used to host these concepts or could it be used by user to define their dialogs ? In this last case, confirmation, warning, information dialogs also should be defined using MDialog ? That would be a mess... We should all agree on the future usage and of the schedule of this and we can not fail this time.
Let's look at things step by step: a) why MDialog/MWizard at various levels * because they inherit from MContext so they would by default only inherit from the MApplication so you would not be able to access informations from the current active MPart because the MPart is in the dialog! * modality: yes really modality, when we think light-weight dialogs it makes sense to scope them on MPart, MPerspective, MWindow and MApplication level b) What's the reason for MFrame and then MDialog, MWizard, ... . - MFrame represents the Frame things are happening in - it only holds the bounds information (plus bindings, .... from a NONE-Visual-Point) - MDialog represents a content with various amounts of buttons (Ok, Cancel, Abort) - MWizard holds pages an but has a fixed amount of buttons (Next, Previous, Ok, Cancel)
Hi all, I've tried to use the MDialog for this usecase: I have a MPart which contains a button that opens a Dialog (MDialog in this case). The dialog contains a list of values from which I have to chose one. Now, the list is built up by NatTable with GlazedLists, so that I need some injections (e.g., some DAOs). The MDialog element would be helpful in this case since I could use it without injecting classes manually (by ContextInjectionFactory). IMHO the MDialog misses some handler properties (i.e., handlers for "OK" or "Cancel" action). So far, Ralf.
(In reply to Wim Jongman from comment #20) > (In reply to Lars Vogel from comment #17) > > I would prefer if we do this work after the Eclipse 4.5 release. > > I agree. I would like to discuss some use cases and forthcoming API on how > the user should operate these things. If we are not changing the current implementation then we better remove ALL the Dialog stuff in 4.5 - the current stuff is just incorrect and leads developers into the wrong direction.
(In reply to Ralf Heydenreich from comment #23) > Hi all, > I've tried to use the MDialog for this usecase: I have a MPart which > contains a button that opens a Dialog (MDialog in this case). The dialog > contains a list of values from which I have to chose one. Now, the list is > built up by NatTable with GlazedLists, so that I need some injections (e.g., > some DAOs). The MDialog element would be helpful in this case since I could > use it without injecting classes manually (by ContextInjectionFactory). IMHO > the MDialog misses some handler properties (i.e., handlers for "OK" or > "Cancel" action). > > So far, > Ralf. the current model does not yet have them but my idea was / is to add an List<MCommand> to MDialog who represent the buttons but I think we need to reschedule for 4.6.
(In reply to Thomas Schindl from comment #24) > If we are not changing the current implementation then we better remove ALL > the Dialog stuff in 4.5 - the current stuff is just incorrect and leads > developers into the wrong direction. I would not mind that.
(In reply to Wim Jongman from comment #26) > (In reply to Thomas Schindl from comment #24) > > > If we are not changing the current implementation then we better remove ALL > > the Dialog stuff in 4.5 - the current stuff is just incorrect and leads > > developers into the wrong direction. > > I would not mind that. The dialog and wizard element was introduce in 4.4 and the suggestion to remove before the 4.4 release was voted down. See https://dev.eclipse.org/mhonarc/lists/e4-dev/msg08275.html
I guess its once more too late for deleting this broken APIs!
(In reply to Thomas Schindl from comment #28) > I guess its once more too late for deleting this broken APIs! Not sure what you mean but we have not yet reached M6 which is our API freeze.
I guess I better make a new bug for the deletion of the API
(In reply to Thomas Schindl from comment #30) > I guess I better make a new bug for the deletion of the API If you still plan to rework the MDialog and MWizard API, we can use this bug report.
Olivier, can you provide a Gerrit review for your ideas? This is not API so we still can change it for 4.6.
Lars, I am sorry but I do not have enough time to fix the global problem for the moment.. What would be the deadline for it ? A first step would be to remove this ambiguous objects from application model or set it as deprecated. MDialog is totally useless and is a way to display the data (pref, properties, wizards...). IMHO it is a renderer point of view. What we need is to design a hierarchy of different objects (preferences, wizards, properties...), without considering if they are rendered in a dialog or not... Then I will not spend a week on this problem without having a real discussion on what we want and how we will do it. There are a lot of different point of view with different solutions (extension point, DS, model, ...). This bug needs to refactor the model and to fix all the regarding objects like editors, data binding, UIEvents, renderers, ... There are a lot of stuffs to manage. I am not aware of all the impacts when the meta model is changed... Depending on the rush, I can try to make a first version for preference pages...If I focus on it the model would be : 'Preferences' contain a hierarchy of 'Preference pages'. A preference page would be bound to a pojo class and that's it. The scoped preference store must also be rewritten outside of org.eclipse.ui (interface is in JFace, implementation is in org.eclipse.ui), and the preference store policy could be defined on the 'Preferences' root object. If we agree on this first step, we could then move forward to wizards and properties.. So, may be, opening 3 bugs for each concepts would be a good idea and we could keep this bug for the main definition of the main concepts ?
(In reply to Olivier Prouvost from comment #33) This sounds like we better deliver a good solution for 4.7 rather than rushing something into 4.6.
(In reply to Dani Megert from comment #34) > (In reply to Olivier Prouvost from comment #33) > > This sounds like we better deliver a good solution for 4.7 rather than > rushing something into 4.6. We already have a (really bad) solution available in 4.5 as non-api. I will have a look at Toms patches and see if we can improve it. But this will not become API in 4.6 in any case.
we are planning to remove these elements
See Bug 531054
