[cells-devel] Something like a def-family-observer?

[Ken Tilton]

Peter Hildebrandt wrote:

OK, now that I am up to speed, let's go back to your original query.

> 
> Say, I have a model M that depends on the structure of a family tree.  
> One  of M's slots is therefore depending on the root of the family tree: 
> (c?  root).  However, I want M to know about changes in the family tree, 
> like,  say, when a child or grandchild is added.  Apparently cells (at 
> least the  cells_2.0 branch required by cells-gtk) does not broadcast 
> change messages  to the parents of a node (which I guess is the right 
> thing in 99% of the  cases).
> 
> What's the best way to deal with that?
> 
> (i) Is there some mechanism for this purpose present in cells? Or
> (ii) Do I roll my own special case solution? Or
> (iii) Is it worthwhile to build some general purpose solution to this  
> problem?
> 
> My approach towards (ii) (I haven't coded anything yet, waiting for you  
> comments) would be something like building an observer tree each node 
> of  which observes one node in the family tree.  Something like this:
> - Design a tiny tree observer model ("tto"?), suited to observing one  
> family node
> (defmodel tty (family) (observed observed-kids reports-to))
> 
> - Every tto knows about the parent model (M from above) and does the 
> right  thing when it sees a change (say, call a closure)
> - If the observed nodes has kids, it instantiates tto kids of its own 
> to  match the kids of the observed tree
>    (def-c-output observed ((self tto))
>      (make-tto :observed (c? new-value) :observed-kids (c? (kids  
> new-value)))
>      (setf (kids self) (mapcar (lambda (kid) (make-tto :observed (c? 
> kid)  :observed-kids (c? (kids kid)))) (kids new-value)
>    ...)
>    (def-c-output observed-kids ((self tto))
>    ...)
> 
> - Changing the root slot in M results in the instantiation of a tto for  
> the root
> 
> I guess that would work ... but I feel there must be a more elegant  
> solution. 

Einstein's "but no simpler" applies here -- an elegant bit of glue 
/should/ look a little tortuous, cuz glue itself is a hack.

You have two requirements, one that the view see changes in the model, 
the other that the model not know about the view. Oops: three, we are 
talking across an API to a C library. This will be fun. :)

tto seems about right. I said earlier you want a thingy isomorphism, and 
tto tries to achieve that without forcing the model to know about its 
view. I might have had a tree-view be a family of sub-tree-views, but 
that would just be my version of tto. But we also want our GTk wrapper 
to align neatly with GTK, which uses a TreeModel to cooperate with the 
TreeView, so... your tto is TreeModel, I think, and TreeModel is 
tree-store IIUC.

I would blend tto ideas into tree-store, have tree-store talk to the 
TreeModel on the C side and let TreeModel then talk to TreeView.

kt