Bug 162595

Comment 1 Pawel Piech 2006-10-27 13:01:47 EDT

Created attachment 52865 [details]
Patch to LaunchViewUpdatePolicy.java@@1.14

Comment 2 Darin Wright 2006-10-27 14:17:31 EDT

In the new context API an ACTIVATED event represents a new state. This corresponds to a CONTENT change in a model. That is, when the content changes, we have a new state that should be activated. A STATE event represents an existing context whose state has changed (but it's different than an activation, since source/variables will not be refreshed by default). So, ACTIVATE == update everything for the new state, and STATE == update commands because the thing that was activated has changed.

The generalization you want to make is that when a parent changes state, a child is considered to have changed state. You are doing this by firing a content/state change on the parent, which refreshes the view at that subtree.

I think the issue is whether children should be consdiered to have changed state when a parent does. Similarly, should a child be consdiered to have changed content when a parent does (this is more disputable)?

In general, I think this is hard to tell, and may be model specific. For example a parent changing content may just indicate that a child was added or removed, but does not indicate that the state of an existing child changed. I think state can also *not* be universally applied to all children - i.e. if a thread resumes, one might consider its parent's state to have changed (i.e. number of suspended threads changed), but the inverse is not true (i.e. the state of all threads did not change).

In your case you want to represent that all children have changed state. I think we should either have a way to explicitly specify this in the delta, or have the delta explicitly specify it - i.e a delta with a state change for the target and all resumed threads would achieve this.

Comment 3 Pawel Piech 2006-10-27 15:04:38 EDT

I don't quite follow the logic wrt ACTIVATED vs STATE, I guess I have to look at the implementation to fully understand it.  But I agree with your conclusion: it's unclear whether state of the children should be updated on account of a IModelDelta.CONTENT of a parent.  

I would would vote for adding another flag to IModelDelta, because fetching all the children in the proxy might be unnecessary and expensive.  That's because in practice this only affects the selected item and moreover the affected children may not be even visible (or known) to the view model.

Comment 4 Pawel Piech 2007-03-21 10:21:53 EDT

Any chance this problem may be looked at in 3.3 still?
Thanks
Pawel

Comment 5 Darin Wright 2007-04-30 14:32:13 EDT

Not planned for 3.3. I think there could be issues here:

* Requires a new model delta flag to indicate that all children should be considered changed as well (and we need to spec what this means if child deltas are present). Adding a new flag now would break eixsting context provider implementations.
* I think this could cause subtle problems when firing a delta where a parent CONTENT changes, and a child has a SELECT flag - this could cause a double notification as the selection occurrs (activating a context), and then the content change is processed by another listener, firing another content change for the same element that as just activated.

Comment 6 Pawel Piech 2007-04-30 17:22:06 EDT

I was actually thinking that the IModelDelta.CONTENT event could translate into a corresponding DebugContextEvent.CONTENT event.  Hopefully this won't affect content providers in anyway, just the actions and views that listen to the context events.

BTW, I'm finding that this event is also needed in order to implement pin+clone properly:  If a view is pinned to a context, it needs to know when a parent context is changed so that it can check to make sure that the pinned context still exists.  

Comment 7 Darin Wright 2008-04-24 12:31:12 EDT

Marking as a dup of a newer bug.

*** This bug has been marked as a duplicate of bug 224477 ***