On Sunday 21 Nov 2010 9:57:06 am Peter Dinges wrote:
> Unfortunately, I think I do not fully grasp why CU events are easier for
> unknown listeners. All that a change from CU to WS events seems to require
> is maybe a relocation of the registration code(?)
CU and WS are meant for different scenarios. Studying senders of model: will 
make the context clear. CU is for situations where the views are intentionally 
decoupled from the object being observed (model).

> Suppose we have a viewer as you proposed. When a value in the viewer is
> changed,
> - with CU events, viewer would issue "self changed: #valueUpdate";
> - with WS events, viewer would issue "self triggerEvent: #valueUpdate".
The viewer does not know the number and kind of listeners interested in the 
changes so it cannot register handlers for them. Of course, you could add a 
method in the Viewer that Watchers can call when created to register a handler 
for them but it would only be duplicating CU logic in a roundabout way.

> Why is it more complicated? At some point you have to tell the watcher
> which viewer to watch. So couldn't you just have a method
A watcher is for a single variable in a morph. When you click on 'simple 
watcher' or 'detailed watcher' from a variable's menu in a Viewer, the watcher 
is created to get/set that variable from that morph.

Subbu