Re: [eclipse-incubator-e4-dev] Modelled UI change notification - live mo

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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