I think the first solution in b) is not working because we have to have a containment relationship to identify a move.
Tom Eric Moffatt schrieb: > > Tom, > > of the two approaches you mention I'm more in favor of the first part of > 'b)' but the 'view' cache should be in the WorkbenchWindow rather than > the Workbench. This is because we need a new instance of the view for > each Window (they ciould both be showing the Java Perspsective). This > nicely captures the 'view, it's UI info (label, icon, ttip...) and its > implementation control in one place but allows references to it from > multiple disjoint hierarchies (but never twice in the same hierarchy, > that'd be multi-instance views). > > I'm less inclined towards the proxy approach because it makes structural > changes in the model when switching perspectives and it complicates the > model, neither of which are necessary using the first approach... > > Good point about 'move'; this has to be an atomic operation, not a > remove/recreate pair for the reasons you mention. Is there a way to > arrange the model so that we can get a single 'parent changed' > notification to key the UI update off of? Calculated property perhaps? > > Eric > > > > *Tom Schindl <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 09/28/2008 10:57 AM > Please respond to > E4 developer list <[email protected]> > > > > To > E4 developer list <[email protected]> > cc > > Subject > Re: [eclipse-incubator-e4-dev] Modelled UI change notification - > live model > > > > > > > > > Hi, > > One more thing on this whole topic the rest is going to the bug. The > critical things in are DOM are (if you compare it with an ordinary DOM). > > a) Distinguish between: > - Moving of nodes (e.g. moving ViewPart A from Stack A to Stack B) > - Removing of node (e.g. remove ViewPart A from Stack A) > > This is doable with EMF but this gives us a new headache because this > assumes that we have a containment-relationship (or if you are not a > EMF-guru a bidirectional parent-child-relationship between Stack and View!) > > b) because of a) this means that sharing View Part A in between Stack A > Perspective A and Stack B from Perspective B we suddendly have links in > our model. There are multiple ways to solve this: > - The views are located at another place (e.g. directly under the > workbench) > - We use links and insert Link/Proxy objects where we want share things > (You see this in my extended model!) between views and when a > perspective gets visible all proxy objects are exchanged to the real > view-part and at the place they got removed a new proxy with the link > to the real object > > Tom > > > Eric Moffatt schrieb: >> >> Tom, in one word "sweet!!' I'd been working on wiring up the listeners >> but I'm just not a databinding guru. I've just taken a look at how you >> are wiring up the controls/model and love it...this is a pattern we can >> make great use of. >> >> I'm switching over to using it but I can'tfind SWT text observables for >> 'Items' (i.e. MenuItem, ToolbarItem, CTabItem). I'll make a quick patch >> that adds them (a quick look a 'observeText' shows that this is fairly >> trivial). >> >> Nice one, >> Eric >> >> >> >> *Mike Wilson/Ottawa/[EMAIL PROTECTED] >> Sent by: [EMAIL PROTECTED] >> >> 09/24/2008 01:22 PM >> Please respond to >> E4 developer list <[email protected]> >> >> >> >> To >> E4 developer list <[email protected]> >> cc >> >> Subject >> Re: [eclipse-incubator-e4-dev] Modelled UI change > notification - >> live model >> >> >> >> >> >> >> >> >>> From: Kevin McGuire/Ottawa/[EMAIL PROTECTED] >>> >>> 1) Do we agree this is the behaviour we want? >>> >> I'd certainly like to see this. In particular, when we have talked >> publically about how e4 would be more dynamic/responsive to develop for, >> this was the kind of thing we had in mind. >> >>> 2) When do we we think we'd provide it? >>> >> I'd argue that it's worth thinking about it soon, since there are >> potentially interesting issues w.r.t. state management, SWT widget >> lifecycle, etc. >> >>> 3) I think I can imagine with the current code base how we handle >>> on-the-fly creation and deletion, but what about modification? >>> Right now the factories 'make', they don't 'modify existing'. >>> >> ... and if we end up with a "destroy and recreate" model, we need to do >> a better job of maintaining state than we currently do (e.g. it's not ok >> for the tree to be recreated with all the nodes collapsed, etc.) >> >> McQ._______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl leiter softwareentwicklung/CSO > ------------------------------------------------------------------------ > eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834 > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl leiter softwareentwicklung/CSO ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
