The main problem here is scopeing, each window has an active part. So when i'm a child of window1 i'm only interested in part changes of my window!
I'm 99% sure that most of the part pojos out there is not useing EPartService appropiately when the part is moved between windows because the you need to unregister from the original EPartService and register on the one from the new window! Tom Von meinem iPhone gesendet Am 30.07.2013 um 20:48 schrieb Eric Moffatt <[email protected]>: > For me it seems like we'd be best off to add new life cycle events for these > publish them. Then the logic for handling the 'registered' IPartListener's > could hand off a listener on the event bus (i.e. the events *drive* the > direct listener logic). The set of new events for this will match the > existing 3.x part events unless someone comes up with use cases for others. > > At the same time we should add at least a couple of rendering events > 'PreRender' and 'PostRender' to manage some of the issues we have in the IDE. > For example we listen for 'widget' going non-null as an indication that > something has been rendered but this happens before the internal structure > has been rendered. > > Are there others life cycle events that should be under discussion ? > > Eric > > > <graycol.gif>Paul Webster ---07/29/2013 01:13:39 PM---On Wed, Jul 24, 2013 at > 5:18 AM, Tom Schindl <[email protected]>wrote: > Hi, > > <ecblank.gif> > From: > <ecblank.gif> > Paul Webster <[email protected]> > <ecblank.gif> > To: > <ecblank.gif> > E4 Project developer mailing list <[email protected]>, > <ecblank.gif> > Date: > <ecblank.gif> > 07/29/2013 01:13 PM > <ecblank.gif> > Subject: > <ecblank.gif> > Re: [e4-dev] IPartListener - really once more Listeners? > <ecblank.gif> > Sent by: > <ecblank.gif> > [email protected] > > > > On Wed, Jul 24, 2013 at 5:18 AM, Tom Schindl <[email protected]> > wrote: > Hi, > > First of all I'm not sure why we are using Listeners here once more > instead of sending out the information through our EventBroker because > this once more traps our users into listener leaks. > > We've been talking about this as well. > > Our listener-for-information pattern has been replaced in Eclipse4 with > IEclipseContext.get(*) + the RATs (a unit of work that depends on that > information). But while this pattern is great for information (the active > part) and is scoped (the RAT is at a particular IEclipseContext instance) it > probably doesn't translated well for some of our larger listener patterns, > like partDeactivated/partHidden/partVisible etc. > > So if firing events is a much better fit for events than the listeners, we > would need to look at 1) the pattern over a couple of listeners we want to > replace and 2) how can we scope it. ex: our IEventBroker.subscribe(*) can > take an LDAP filter as well as topic when registering a handler. Do we need > to add more information to our eventHandler properties that we use to > register as a service? Or is it properties in the event's that are posted > that need extra information. > > PW > > > > -- > Paul Webster > Hi floor. Make me a sammich! - GIR > _______________________________________________ > 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
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
