Regarding the start up, I remember a discussion between Lars and Tom that one problem could be solved by swapping parts of the initialization. I don't recall the details. Lars? Tom? If you don't remember, I can track down the bug number.
Regards, Wim On Wed, Aug 7, 2013 at 9:06 PM, Eric Moffatt <[email protected]> wrote: > Wim, great blog !! Do you submit these things to PlanetEclipse ? The > reason I didn't re-use the existing 'views' extension is simply that its > schema enforces a restriction that the 'class' implement ViewPart > (IViewPart?). If you were to use the existing 'view' extension then you > would get incorrect information on both the 'class' definition link (the > initial values in the dialog would have you subclassing ViewPart) and the > 'Browse' (which only looks for IViewParts). I don't know of any way to > 'mix' both behaviors in the same Extension... > > I'll see if I can cover both yourand Jonas' other questions at the same > time since they're somewhat related: > > The ultimate goal is to allow us to consume and render any valid UI model > containing a mix of legacy and e4 components. There are a few steps > required in order to accomplish this: > > 1) Fix our current code so that we *DO NOT* mess with the model either at > startup or shutdown. This means removing any code on the IDE side that > seeks to manipulate the model (We will have to manage new / stale > contributions somehow but this is part of Jonas' question so we'll get to > it later). This should allow the RCP client to construct a mixed model of > their own specification, knowing we aren't going to do dumb things like > adding a Search bar or Perspective Switcher. > > My current 'plan' is to see if we can produce a two-stage approach to > defining the model in the IDE. First we'd take the existing LegacyIDE.xmi > file combined with any extensions (either through Extension Points or > fragments / processors) and produce the starting IDE *for a particular > install*. From that point this would become the starting model for all new > workspaces. From that point on we should simply store / load the model > without change. > > 2) We need to change our rendering setup to allow us to arbitrarily 'grow' > any necessary 3.x artifacts as needed (including those for any direct e4 > parts). This will mean moving code out of our CompatibilityPart[View | > Editor] and into some part of the rendering stage. This will require that > we introduce some new life cycle events...see below. > > *NOTE:* Editors are going to be significantly more work since we first > have to work out what the model's "EditorDescriptor" looks like and how it > works (including suffix bindings, content types...). Perhaps we should just > scrape the current org.eclipse.ui.editors extension point for what it has ? > > Now on to Jonas' question regarding fragment processing...I haven't paid > much attention to this as it wasn't required for the IDE. My impression > from the EclipseCon BOF was that it's quite a mess presently. Not only are > there the issues you're seeing but we have no way currently to apply model > processors to newly created elements (i.e. a newly opening window). From my > POV model processing == registry processing; in fact our some of our > current registry processing is already handled through model processors but > not all (i.e. ViewRegistry processing). > > There are a number of things we might do here: > > 1) Add new life cycle events; some matching the current IPartListener > events add at least two others "AboutToRender" and "FinishedRendering". > This will allow us to extend the model processing to listen on the new > events and take appropriate action (likely needs a change to the fragments > EP along the lines of an 'ApplyWhen' field...). > > 2) Fix the model to at least allow Commands / Handlers to be late bound > (i.e. relax the MHandler's model to allow 'null' for the Command ref) and > set the reference when needed (store the command ID in the persistentData > map ?). > > 3) Freaking define the start up life cycle as a state machine, with * > diagrams* ! In my experience the exercise of defining the diagram > provides focus for the code; what has to be done and where it should go > should all be in reference to the diagram (possibly leading to changes in > the diagram should breaking use cases be discovered). Transitions through > this state machine should all be published on the event bus... > > BTW, two questions about the current fragment processing: > > 1) Why don't we handle processing a model fragment by running it through a > regular ModelProcessor (called FragmentProcessor) ? It seems somewhat > strange that we can't build the fragment processing on top of the more > general model processor. > > 2) I see that there's a sorting stage in place to address the fragment > ordering issues. My expectation based on our uniform lack of success in > doing this for the 3.x extensions is that we might be better off going with > the pattern we use to process 'org.eclipse.ui.menus' extensions. These > extensions match the 'add this at location <x>' approach we use for > fragments but rather than sorting them we simply use the following: > > - Attempt to locate the insertion point. > - Found it....success, process the fragment > - Not found...fail, add it back at the end of the list to be > processed later > > We're only finished when the list is empty or when a full pass over it has > *no* successes (meaning that everything remaining cannot be sited). > > This works extremely well in that it completely ignores the order in which > the extensions arrive from the registry and handles even deeply nested > locations. Note that in this case we never have to look at the *contents* > of a fragment since once it's applied any children added will be available > as site locations for subsequent extensions...should we give this a try > while we're refactoring the processing ? > > Dang ! This is a bit longer than I expected. I'd love to start up the > conversation about the start up life cycle, who wants to toss out the first > cut..;-). > > Onwards, > Eric > > > [image: Inactive hide details for Wim Jongman ---08/06/2013 05:08:07 > AM---Hi, Great changes guys! "e4view". In case you missed it, I ha]Wim > Jongman ---08/06/2013 05:08:07 AM---Hi, Great changes guys! "e4view". In > case you missed it, I have blogged about > > > > From: > > > Wim Jongman <[email protected]> > > To: > > > E4 Project developer mailing list <[email protected]>, > > Date: > > > 08/06/2013 05:08 AM > > Subject: > > > Re: [e4-dev] Focus for Luna > > Sent by: > > > [email protected] > ------------------------------ > > > > Hi, > > Great changes guys! "e4view". In case you missed it, I have blogged about > this change [1]. Eric, can you share some of the implementation details > with us? Do you create an invisible counterpart e3 view as a bridge? > > What are the plans for the next step? > > Cheers, > > Wim > > > > [1] * > http://industrial-tsi-wim.blogspot.nl/2013/08/a-giant-leap-for-eclipse-rcp.html > *<http://industrial-tsi-wim.blogspot.nl/2013/08/a-giant-leap-for-eclipse-rcp.html> > > > On Sun, Aug 4, 2013 at 4:41 PM, Jonas Helming <* > [email protected]* <[email protected]>> wrote: > > Hi, > are there any plans to support the following use case: > I have an existing 3.x application running on compat layer. Now I want > to add a new view using fragments, meaning I plug a new e4 view into the > model which was created by the compat layer? > Currently this is not possible, because the model is not fully created > when fragments or processors are merged. > > Regards > Jonas > > Am 02.08.2013 16:19, schrieb Eric Moffatt: > > Wim, we've already started on at least part of if. I've just > committed changes to the org.eclipse.ui.views extension point that > allows > someone using Eclipse 4 to declare a new view with its implementation > being > e4 style (DI...). This is the first test case; if it seems to be the > correct direction we expect to do this for other extensions such as > org.eclipse.ui.menus (e4 Handlers...). > > We also have ongoing work in progress that will alter how we > integrate with the legacy 3.x API so that creation of any necessary 3.x > artifacts (Workbench[Window, Page], IWorkbenchParts, ViewReferences, > PartSites...) all get created 'automagically' during the rendering > stage. > Part of this will be to add the new life cycle events to allow this to > happen. Once done your mixed model RCP app should be capable of > consuming > most (if not all) existing views / editors, even those that need access > to > EditorReferences... > > In fact we've just been discussing how we might override the > default renderer factory so that we can supply ones specific to the IDE > (so > that they can create the necessary 3.x artifacts without introducing > dependencies. > > Onwards, > Eric > > [image: Inactive hide details for Wim Jongman ---08/02/2013 > 08:28:12 AM---Hi, When we spoke on the e4/RCP BoF it was made clear > that al]Wim > Jongman ---08/02/2013 08:28:12 AM---Hi, When we spoke on the e4/RCP BoF > it > was made clear that allowing the e4 > > > From: > > > Wim Jongman *<[email protected]>* <[email protected]> > > To: > > > E4 Project developer mailing list *<[email protected]>*<[email protected]>, > > > Date: > > > 08/02/2013 08:28 AM > > Subject: > > > [e4-dev] Focus for Luna > > Sent by: > > * > **[email protected]* <[email protected]> > > ------------------------------ > > > > Hi, > > When we spoke on the e4/RCP BoF it was made clear that allowing the e4 > programming model on e3 was the first priority for Luna (or maybe that was > what I wanted to hear?). > > On the plan [1] the first item on the list is the effort to use e4 in > the e3 context. However, when I go to the milestone breakdown [2] all of > these items are still on the unscheduled list. > > Is there already an idea what the current focus is for Luna? > > Thanks and best regards, > > Wim > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > > _______________________________________________ > e4-dev mailing list > *[email protected]* <[email protected]> > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<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 > >
<<graycol.gif>>
<<ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
