[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Modelled UI change notification - live model
|
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 <tom.schindl@xxxxxxxxxxxxxxx>*
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>
> 09/28/2008 10:57 AM
> Please respond to
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
>
>
> To
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
> 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/IBM@IBMCA*
>> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>>
>> 09/24/2008 01:22 PM
>> Please respond to
>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>>
>>
>>
>> To
>> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> cc
>>
>> Subject
>> Re: [eclipse-incubator-e4-dev] Modelled UI change
> notification -
>> live model
>>
>>
>>
>>
>>
>>
>>
>>
>>> From: Kevin McGuire/Ottawa/IBM@IBMCA
>>>
>>> 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
>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> eclipse-incubator-e4-dev mailing list
>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> 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
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> 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
