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
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
