https://github.com/E4Examples/mdialog01/blob/master/mdialog01/src/mdialog01/handlers/OpenHandler.java
On Wed, Apr 2, 2014 at 7:44 PM, Eric Moffatt <[email protected]> wrote: > Olivier, I'll put my comments in context below...in green... > > Onwards, > Eric > > > [image: Inactive hide details for Olivier Prouvost ---04/01/2014 02:55:48 > AM---If we analyze how E3 ui extension points have been migra]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 <[email protected]> > > To: > > > E4 Project developer mailing list <[email protected]>, > > Date: > > > 04/01/2014 02:55 AM > > Subject: > > > Re: [e4-dev] MWizard and MDialog > > Sent by: > > > [email protected] > ------------------------------ > > > > > 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). > > In 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. > > > > 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. > > 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. > > > > 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*<https://github.com/opcoach/e4Preferences> > 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 > <*[email protected]*<[email protected]>> > 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 > *[email protected]* <[email protected]> > https://dev.eclipse.org/mailman/listinfo/e4-dev > > _______________________________________________ > 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: ecblank.gif>>
<<inline: graycol.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
