| Re: [e4-dev] MWizard and MDialog |
Olivier, I'll put my comments in context below...in green...
Onwards,
Eric
Olivier Prouvost ---04/01/2014 02:55:48 AM---If we analyze how E3 ui extension points have been migrated to the application model, it could be lo
From:
Olivier Prouvost <olivier.prouvost@xxxxxxxxxxx>
To:
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:
04/01/2014 02:55 AM
Subject:
Re: [e4-dev] MWizard and MDialog
Sent by:
e4-dev-bounces@xxxxxxxxxxxIn general most dialogs are indeed sets of 'boring' code (mostly around setting up the widget layout/listeners...). The reason for having the model elements is to allow hooking them into the IEclipseContext hierarchy more easily.
If we analyze how E3 ui extension points have been migrated to the application model, it could be logical to find some concepts in the application model. Wizards, preferences or properties could be defined there. There is a hierarchy of object and a generic dialog that can display these objects. Today, in E4 there is no way to display these information unless writing boring code (always the same for all applications).
My suspicion is that you may have left the various MDialog's 'toBeRendered' state as 'true'. The idea is that you'd leave the TBR as false until you want the dialog to appear then change it to 'true' to have the rendering engine process it. In order to be useful it's likely that each MDialog instance would have its *own* renderer so that it gets filled in correctly.
So, having specific dialogs in the model seems to be a good idea, but not generic ‘dialog’ as it is done today… A general dialog asking confirmation or some information can be opened easily in an handler, and there is no objects hierarchy to manage. This is not its place in model. I tried the new implementation with a dialog and a wizard and everything has been opened at startup ! Absolutely useless.
The other solution could be to stop to change application model every month and to keep the old extension point mechanism which is quiet powerful. For the moment I manage pure E4 preferences using a plugin which defines a generic handler to open the dialog, and an extension point similar to the definition in E3. This plugin is available on my github and I will probably propose to include it in E4 if there are no other solutions proposed to manage this concept. In this case, properties and wizards could be managed in the same way…
Of course this plugin manage only preferences using JFace and not javafx… and it is not the ‘good’ solution.
What is your opinion about it ?
Le 28 mars 2014 à 18:40, Wim Jongman <wim.jongman@xxxxxxxxx> a écrit :
What is the plan with these two embryo's? Tom had some plans with them in efxclipse. Was this done?
_______________________________________________
Please give me an heads up if these are killed so that we can revert the changes in the model editor.
Cheers,
Wim
_______________________________________________
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
