Olivier, I'll put my comments in context below...in green...

Onwards,
Eric



                                                                       
  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  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]> 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]
      https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to