Here's a question for you cells wizards out there (and Kenny in particular):
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. I'm eager to hear your suggestions.
Thanks, Peter
Background:
If you have seen my ton of mails on the cells-gtk-devel list, you know I'm doing some GUI work with cells-gtk at the moment. I ran into the following issue: cells-gtk can use a family tree as a natural representation of the contents of a tree-view. However, when I change the items in that family tree, cells-gtk currently has no way of updating the C data structure correspondingly.
The tree-model data type GTK uses internally is nasty to deal with, and therefore I really want to capsulate everything away. I have already figured out how to add/remove rows and children in the model, so I'd be ready to modify the C data type to reflect changes in the family tree. I'm just looking for the Right Way to do it.
Peter Hildebrandt wrote:
Here's a question for you cells wizards out there (and Kenny in particular):
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).
More below, just retro-inserting notes: normally in /my/ work the parent slot is not even a Cell, but I /have/ done that a couple of times on certain subclasses of Family and it did work.
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).
Confused: The kids slot is a Cell, so any rule anywhere (on slots not just the ascendants) that references (kids <whatever>) will get kicked off whent that changes. More below on this.
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. I'm eager to hear your suggestions.
Thanks, Peter
Background:
If you have seen my ton of mails on the cells-gtk-devel list, you know I'm doing some GUI work with cells-gtk at the moment. I ran into the following issue: cells-gtk can use a family tree as a natural representation of the contents of a tree-view. However, when I change the items in that family tree, cells-gtk currently has no way of updating the C data structure correspondingly.
This sentence seems crucial and puzzles me some. What precisely is meant by "when I change the items in that family tree"? Do you mean reorgamize the tree by moving kids between parents?
As for "update the C data structure correspondingly", well, /what/ C data structure, this is the first I have heard of it. Do you mean the C struct implementing the tree view, or a C struct one might be "inspecting" by mapping its hierarchy to a tree of widgets?
The tree-model data type GTK uses internally is nasty to deal with, and therefore I really want to capsulate everything away. I have already figured out how to add/remove rows and children in the model, so I'd be ready to modify the C data type to reflect changes in the family tree. I'm just looking for the Right Way to do it.
Let me clarify a couple of things first. btw, I do not even have Cells-Gtk installed anywhere so I may have to do that if things get too complicated.
First of all, my models normally do not have the parent slot as a Cell at all, meaning I do not move things from one parent to another. But! There have been times when I did that and it did seem to work, so let's keep that in mind going forward.
Second, without looking I am almost certain the kids slot of the family class already does let applications react to changes to kids, so I am not clear on why TTO is necessary (unless we are talking about also needing the parent to be a Cell, which as I said might Just Work if we put our minds to it).
Third, I'd like to understand the functionality better. Is the goal to manipulate a tree on the C side via a [Cells-]Gtk tree view? Or just dynamically restucture a treeview? This is the same question as above where I ask about what is meant by "update the C data structure"?
cheers, ken
Ken,
thanks for your reply, and sorry about the confusion. I guess I have been working on this for too long :)
So, here's a second try. I'll try to write some code to make clear what this is about, and what I want to do.
First, here's what we have:
My family tree:
(defmodel node (family) (age :accessor age :initarg :age :initform (c-in 17))) (defparameter root (make-instance 'node :md-name "root")) (push (make-instance 'node :md-name "child1" :age 23) (kids root)) (push (make-instance 'node :md-name "child2" :age 32) (kids root)) (push (make-instance 'node :md-name "grand child" :age 3) (kids (first (kids root))))
A tree-view widget (note that the tree view widget displays something called a "tree model". That is a data structure somewhere in GTK that can be build and accessed through a bunch of messy gtk function calls. So what we have to do is go through our family and build the tree model accordingly. Our func is kinda like a fax that makes a copy and sends it out to the recipient. If the original changes, we have to send the fax again.)
(defmodel tree-view (family) ((roots :accessor roots :initform (c-in nil) :initarg :roots) ;; other slots, GUI stuff ))
(def-c-output roots ((self tree-view)) ;; cells-gtk has lots of calls to GTK here ;; to build a tree model starting from roots (see above) (print (list "roots have changed" new-value)))
(defparameter tview (make-instance 'tree-view))
I connect it to the kids of the root
(setf (roots tview) (kids root)) => "roots have changed ...." And there it is:
md-name age --------------------- child2 32 +-grand child 3 child1 23
So far, it is all there in cells-gtk, and it all works.
However, if my family tree /changes/, meaning - somewhere a node is added/removed - somewhere a slot is modified
==> I'd like the treeview to learn about it.
How do we do this?
(setf (md-name (first (kids root))) "My child") => "My child"
(push (make-instance 'node :md-name "child3") (kids root)) => (child3 child2 child1)
... but the def-c-output never finds out about it, and thus no one ever gets round to up.
I can trigger it by re-setfing the place:
(setf (roots tview) (kids root)) => ("roots have changed" (child3 child2 child1)) => (child3 child2 child1)
But that has three downsides:
(1) I have to call setf manually (even when I disguise it with some macro as (update-tree tview)) (2) what do I do, when roots is a dependent cell in the first place? ... :roots (c? (kids root)) (3) the whole tree has to be reconstructed everytime a little bit changes
In short: The tree-view interface does not come across cells-like at all. And I guess that is, because the way of looking at it is just not a cells way.
So I came up with the idea to make the interface to the tree-view a tree of cells, so that in effect for every box that is displayed in the treeview there is a dependent cell in the treeview (Instead of one cell connecting to the kids of the root).
One way to do this would be to have an observer object
(defmodel tto () ((obs :accessor obs :initarg :obs) (corresponding-point-in-gtk)) (def-c-output obs ((self tto)) (call-gtk-and-set corresponding-point-in-gtk new-value))
Then we would make six of these, two per node (name and age) when roots is assigned:
(def-c-output roots ((self tree-view)) (mapcar (lambda (nd) (make-instance 'tto :obs (c? (md-name nd)) :corresponding... ...)) (roots self)) ;; of course we'll have to recurse into the kids and the names of the accessors ;; are supplied somewhere to the treeview etc.
Additionally we'd have some sort of structure observer that listens on the kids of every node (here three for three nodes) and reacts to changes by adding/deleting rows to the tree-view. Additionally it'd have to create/remove tto's to listen to the slots of new nodes or stop listening to removed nodes.
Another option would be what I dubbed the "family-observer": Some piece of magic that gets notified when any slot in a model or any of its decendents gets modified. The notification would idealy include the modified node, the modified slot, the new-value and a path from the root to the node (could be a closure, (lambda (n) (nth 2 (nth 3 (nth 0 (kids n] => (lambda root) is the modified node, or just a list '(0 3 2)). That family observer could then take this notification/message and do the appropriate action.
I do not understand cells enough to judge whether this would even be possible. So maybe there is something, some instance where all state changes get passed through, that could filter out the ones going to root or its descendents, maybe not.
Well, I hope it's clearer now what I wish to do.
In reply to your comments:
On Tue, 11 Dec 2007 21:03:39 +0100, Ken Tilton kennytilton@optonline.net wrote:
More below, just retro-inserting notes: normally in /my/ work the parent slot is not even a Cell, but I /have/ done that a couple of times on certain subclasses of Family and it did work.
Yeah, thanks for pointing that out. I got that confused from time to time and was wondering why a (c? parent) does not learn about (kids parent).
Confused: The kids slot is a Cell, so any rule anywhere (on slots not just the ascendants) that references (kids <whatever>) will get kicked off whent that changes. More below on this.
I was wondering whether there would be a way to kick of that rule when something deeper down in the tree gets modified (see above, the family observer)
If you have seen my ton of mails on the cells-gtk-devel list, you know I'm doing some GUI work with cells-gtk at the moment. I ran into the following issue: cells-gtk can use a family tree as a natural representation of the contents of a tree-view. However, when I change the items in that family tree, cells-gtk currently has no way of updating the C data structure correspondingly.
This sentence seems crucial and puzzles me some. What precisely is meant by "when I change the items in that family tree"? Do you mean reorgamize the tree by moving kids between parents?
Maybe this, maybe changing a cell slot on a node in the tree, maybe adding kids, maybe removing them. In effect I want to keep the projection of the tree onto the tree-view consistent with the tree.
As for "update the C data structure correspondingly", well, /what/ C data structure, this is the first I have heard of it. Do you mean the C struct implementing the tree view, or a C struct one might be "inspecting" by mapping its hierarchy to a tree of widgets?
The gtk tree-view displays an internal data structure, consisting of rows of "cells". rows can have children. Whenever we want to put some lisp structure in the treeview, we have to traverse it and build the corresponding gtk stuff.
Let me clarify a couple of things first. btw, I do not even have Cells-Gtk installed anywhere so I may have to do that if things get too complicated.
I hope it won't come that far :) I really appreciate your help, esp. given you won't even use cells-gtk.
First of all, my models normally do not have the parent slot as a Cell at all, meaning I do not move things from one parent to another. But! There have been times when I did that and it did seem to work, so let's keep that in mind going forward.
Probably we won't have to. I believe this one comes out of a misunderstanding -- or am I not getting it?
Second, without looking I am almost certain the kids slot of the family class already does let applications react to changes to kids, so I am not clear on why TTO is necessary (unless we are talking about also needing the parent to be a Cell, which as I said might Just Work if we put our minds to it).
This confuses me. "the kids slot of the family class already does let applications react to changes to kids" -- what exactly do you mean by that? Adding/removing kids? Changes to the kids themselves (setf (md-name (first (kids root))) "Joe")?
To me it looks like neither happens.
(defparameter root (make-instance 'node :md-name "Root" :kids (c-in nil))) => ROOT (defparameter tview (make-instance 'tree-view :roots (c? (kids root)))) => TVIEW (push (make-instance 'node :md-name "child") (kids root)) => (child)
====> Nothing
(roots tview) => ("roots have changed" (child)) => (child)
(i.e. the def-c-observer only gets called once I query the slot)
Third, I'd like to understand the functionality better. Is the goal to manipulate a tree on the C side via a [Cells-]Gtk tree view? Or just dynamically restucture a treeview? This is the same question as above where I ask about what is meant by "update the C data structure"?
The goal is
I modify lisp stuff ==> the GTK tree model stuff ("C data structure") gets updated ==> The treeview reflects my changes to the lisp stuff
It looks like I got myself into quite a mess here ...
Cheers, Peter
Peter Hildebrandt wrote:
Ken,
thanks for your reply, and sorry about the confusion. I guess I have been working on this for too long :)
So, here's a second try. I'll try to write some code to make clear what this is about, and what I want to do.
First, here's what we have:
My family tree:
(defmodel node (family) (age :accessor age :initarg :age :initform (c-in 17))) (defparameter root (make-instance 'node :md-name "root")) (push (make-instance 'node :md-name "child1" :age 23) (kids root)) (push (make-instance 'node :md-name "child2" :age 32) (kids root)) (push (make-instance 'node :md-name "grand child" :age 3) (kids (first (kids root))))
A tree-view widget (note that the tree view widget displays something called a "tree model". That is a data structure somewhere in GTK that can be build and accessed through a bunch of messy gtk function calls. So what we have to do is go through our family and build the tree model accordingly. Our func is kinda like a fax that makes a copy and sends it out to the recipient. If the original changes, we have to send the fax again.)
(defmodel tree-view (family) ((roots :accessor roots :initform (c-in nil) :initarg :roots) ;; other slots, GUI stuff ))
(def-c-output roots ((self tree-view)) ;; cells-gtk has lots of calls to GTK here ;; to build a tree model starting from roots (see above) (print (list "roots have changed" new-value)))
(defparameter tview (make-instance 'tree-view))
I connect it to the kids of the root
(setf (roots tview) (kids root)) => "roots have changed ...." And there it is:
md-name age
child2 32 +-grand child 3 child1 23
So far, it is all there in cells-gtk, and it all works.
However, if my family tree /changes/, meaning
- somewhere a node is added/removed
- somewhere a slot is modified
==> I'd like the treeview to learn about it.
How do we do this?
(setf (md-name (first (kids root))) "My child") => "My child"
(push (make-instance 'node :md-name "child3") (kids root)) => (child3 child2 child1)
... but the def-c-output never finds out about it, and thus no one ever gets round to up.
I can trigger it by re-setfing the place:
(setf (roots tview) (kids root)) => ("roots have changed" (child3 child2 child1)) => (child3 child2 child1)
But that has three downsides:
(1) I have to call setf manually (even when I disguise it with some macro as (update-tree tview)) (2) what do I do, when roots is a dependent cell in the first place? ... :roots (c? (kids root)) (3) the whole tree has to be reconstructed everytime a little bit changes
In short: The tree-view interface does not come across cells-like at all. And I guess that is, because the way of looking at it is just not a cells way.
OK, I understand. You are right, we want the tree-view to update automatically as the model changes, by which I mean either the population of the model or the value of a displayed slot of a node of the model, and normally this is how my GUIs work. It should be easy to get this in cells-gtk.
I may have to build Cells-gtk. Possibly you have missed some existing mechanism in cells-gtk, so I have CCed that list. Or possibly the cells-gtk tree-view got implemented with a static model in mind and it is merely time to break that assumption. No big deal, assuming GTk's API has the chops (which I wager it does).
A question is how much work gets done on the Lisp side. Do we end up with one Lisp widget instance for each observed row? Better yet, for each field of each row? ie, the lisp tree-view runs down the model rooted in "roots" looking for kids of kids and then... hmmm, maybe not, and it looks like I better build Cells-gtk.
Normally what I do is mirror each thingy on the C side with a thingy on Lisp side, so there would be tree-view and then tree-view-row and maybe tree-view-row-field (or tree-view-cell in spreadsheet-ese). To make things super-flexible, I then make those types parameterizable, so I can make a custom tree-view-cell (by subclassing tree-view-cell) and then specify to tree-view that it should use that subclass as it is traversing my data model building up the Lisp tree-view.
At this point, of course, on the Lisp side anyway I can "see" cells-wise everything that is happening, including tree insertion/deletions and changes to slot values of model nodes. The next question is how to tell GTk.
Does Gtk give us the granularity to operate on the tree view, ie, does it allow us to say "remove this row" or change this field of this row to show this new value ("My child")? I think you said yes to this in your prior note. If so, the next question is if we have done the FFI for those bits of the API. :)
I'll stop here since I am just collecting info, but rest assured this is normal stuff and if the GTk API offers the hooks we should have no problem getting information to flow from the lisp side to Gtk, using the ideas hinted at above.
kt
So I came up with the idea to make the interface to the tree-view a tree of cells, so that in effect for every box that is displayed in the treeview there is a dependent cell in the treeview (Instead of one cell connecting to the kids of the root).
One way to do this would be to have an observer object
(defmodel tto () ((obs :accessor obs :initarg :obs) (corresponding-point-in-gtk)) (def-c-output obs ((self tto)) (call-gtk-and-set corresponding-point-in-gtk new-value))
Then we would make six of these, two per node (name and age) when roots is assigned:
(def-c-output roots ((self tree-view)) (mapcar (lambda (nd) (make-instance 'tto :obs (c? (md-name nd)) :corresponding... ...)) (roots self)) ;; of course we'll have to recurse into the kids and the names of the accessors ;; are supplied somewhere to the treeview etc.
Additionally we'd have some sort of structure observer that listens on the kids of every node (here three for three nodes) and reacts to changes by adding/deleting rows to the tree-view. Additionally it'd have to create/remove tto's to listen to the slots of new nodes or stop listening to removed nodes.
Another option would be what I dubbed the "family-observer": Some piece of magic that gets notified when any slot in a model or any of its decendents gets modified. The notification would idealy include the modified node, the modified slot, the new-value and a path from the root to the node (could be a closure, (lambda (n) (nth 2 (nth 3 (nth 0 (kids n] => (lambda root) is the modified node, or just a list '(0 3 2)). That family observer could then take this notification/message and do the appropriate action.
I do not understand cells enough to judge whether this would even be possible. So maybe there is something, some instance where all state changes get passed through, that could filter out the ones going to root or its descendents, maybe not.
Well, I hope it's clearer now what I wish to do.
In reply to your comments:
On Tue, 11 Dec 2007 21:03:39 +0100, Ken Tilton kennytilton@optonline.net wrote:
More below, just retro-inserting notes: normally in /my/ work the parent slot is not even a Cell, but I /have/ done that a couple of times on certain subclasses of Family and it did work.
Yeah, thanks for pointing that out. I got that confused from time to time and was wondering why a (c? parent) does not learn about (kids parent).
Confused: The kids slot is a Cell, so any rule anywhere (on slots not just the ascendants) that references (kids <whatever>) will get kicked off whent that changes. More below on this.
I was wondering whether there would be a way to kick of that rule when something deeper down in the tree gets modified (see above, the family observer)
If you have seen my ton of mails on the cells-gtk-devel list, you know I'm doing some GUI work with cells-gtk at the moment. I ran into the following issue: cells-gtk can use a family tree as a natural representation of the contents of a tree-view. However, when I change the items in that family tree, cells-gtk currently has no way of updating the C data structure correspondingly.
This sentence seems crucial and puzzles me some. What precisely is meant by "when I change the items in that family tree"? Do you mean reorgamize the tree by moving kids between parents?
Maybe this, maybe changing a cell slot on a node in the tree, maybe adding kids, maybe removing them. In effect I want to keep the projection of the tree onto the tree-view consistent with the tree.
As for "update the C data structure correspondingly", well, /what/ C data structure, this is the first I have heard of it. Do you mean the C struct implementing the tree view, or a C struct one might be "inspecting" by mapping its hierarchy to a tree of widgets?
The gtk tree-view displays an internal data structure, consisting of rows of "cells". rows can have children. Whenever we want to put some lisp structure in the treeview, we have to traverse it and build the corresponding gtk stuff.
Let me clarify a couple of things first. btw, I do not even have Cells-Gtk installed anywhere so I may have to do that if things get too complicated.
I hope it won't come that far :) I really appreciate your help, esp. given you won't even use cells-gtk.
First of all, my models normally do not have the parent slot as a Cell at all, meaning I do not move things from one parent to another. But! There have been times when I did that and it did seem to work, so let's keep that in mind going forward.
Probably we won't have to. I believe this one comes out of a misunderstanding -- or am I not getting it?
Second, without looking I am almost certain the kids slot of the family class already does let applications react to changes to kids, so I am not clear on why TTO is necessary (unless we are talking about also needing the parent to be a Cell, which as I said might Just Work if we put our minds to it).
This confuses me. "the kids slot of the family class already does let applications react to changes to kids" -- what exactly do you mean by that? Adding/removing kids? Changes to the kids themselves (setf (md-name (first (kids root))) "Joe")?
To me it looks like neither happens.
(defparameter root (make-instance 'node :md-name "Root" :kids (c-in nil))) => ROOT (defparameter tview (make-instance 'tree-view :roots (c? (kids root)))) => TVIEW (push (make-instance 'node :md-name "child") (kids root)) => (child)
====> Nothing
(roots tview) => ("roots have changed" (child)) => (child)
(i.e. the def-c-observer only gets called once I query the slot)
Third, I'd like to understand the functionality better. Is the goal to manipulate a tree on the C side via a [Cells-]Gtk tree view? Or just dynamically restucture a treeview? This is the same question as above where I ask about what is meant by "update the C data structure"?
The goal is
I modify lisp stuff ==> the GTK tree model stuff ("C data structure") gets updated ==> The treeview reflects my changes to the lisp stuff
It looks like I got myself into quite a mess here ...
Cheers, Peter
A cursory glance at the GTk doc itself does not show things like insert/delete row or set cell value. Can you steer me to those?
If they do not exist, it may well be that the Gtk tree view widget itself was designed with a static model in mind, in which case, yes, you are in for some fun milking what API it does offer. And, again /if/ this is the case, I recommend checking with the Gtk list to see if something has been missed and how they handle what seems like a pretty common requirment.
kt
On Wed, 12 Dec 2007 03:23:38 +0100, Ken Tilton kennytilton@optonline.net wrote:
A cursory glance at the GTk doc itself does not show things like insert/delete row or set cell value. Can you steer me to those?
the API: http://library.gnome.org/devel/gtk/2.11/GtkTreeStore.html
or more readable: http://scentric.net/tutorial/treeview-tutorial.html
The treestore/liststore is the "underlying C data structure" I was talking about in my first email.
In GTK-speak, a treestore/liststore implements the tree-model interface, which is used by the tree-view widget. And all I want is a treebox ;)
Good night (its 430AM over here),
Peter
If they do not exist, it may well be that the Gtk tree view widget itself was designed with a static model in mind, in which case, yes, you are in for some fun milking what API it does offer. And, again /if/ this is the case, I recommend checking with the Gtk list to see if something has been missed and how they handle what seems like a pretty common requirment.
kt
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
Ken Tilton wrote:
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.
Roughly (cuz of rough recall of Cells2):
(defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k)))))))
That handles rows in/out. As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row.
You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o:
(def-family-observer my-tree (<def options?>) slot-1 slot-2)
Expansion left as an exercise. :) It is not inconceivable to have f-o link dynamically to any cell-mediated slot of the model instances, btw.
kt
Ken Tilton wrote:
Ken Tilton wrote:
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.
Roughly (cuz of rough recall of Cells2):
(defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k)))))))
That handles rows in/out.
Left unsaid was that you need an observer specialized on family-observer to relay changes to the Gtk side.
As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row.
You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o:
(def-family-observer my-tree (<def options?>) slot-1 slot-2)
Left unsaid is that def-family-observer expands into:
(defmodel my-tree (family-observer) <slot defs for slot-1 and slot-2> (:default-initargs :slot-1 (c? (slot-1 (md-value self))) :slot-2 <same>))
...and observers for slot-1 and slot-2 specialized on my-tree to relay changes to gtk.
kt
On Wed, 12 Dec 2007 15:36:26 +0100, Ken Tilton kennytilton@optonline.net wrote:
Ken Tilton wrote:
Ken Tilton wrote:
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.
Roughly (cuz of rough recall of Cells2): (defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k))))))) That handles rows in/out.
Left unsaid was that you need an observer specialized on family-observer to relay changes to the Gtk side.
Ah, I get it. Would the following do the trick?
(def-c-observer kids ((self f-o)) (mapcar #'gtk-forget-about-and delete-that-row old-value) (mapcar #'not-to-be old-value)) ;; would i need that?
Help with this one is really appreciated, because I feel I have never quite understood how to handle making instances in a cells slot properly (I how to clean up properly).
As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row. You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o: (def-family-observer my-tree (<def options?>) slot-1 slot-2)
Left unsaid is that def-family-observer expands into:
(defmodel my-tree (family-observer) <slot defs for slot-1 and slot-2> (:default-initargs :slot-1 (c? (slot-1 (md-value self))) :slot-2 <same>))
...and observers for slot-1 and slot-2 specialized on my-tree to relay changes to gtk.
Cool. Gotta love lisp, macros, and cells. I wonder how many lines of C that would make.
As to the current status, I'm messing with CFFI to get some more bookkeeping deferred to the GTK side. Once you get started there's a function of everything :)
Peter
kt
Peter Hildebrandt wrote:
On Wed, 12 Dec 2007 15:36:26 +0100, Ken Tilton kennytilton@optonline.net wrote:
Ken Tilton wrote:
Ken Tilton wrote:
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.
Roughly (cuz of rough recall of Cells2): (defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k))))))) That handles rows in/out.
Left unsaid was that you need an observer specialized on family-observer to relay changes to the Gtk side.
Ah, I get it. Would the following do the trick?
(def-c-observer kids ((self f-o)) (mapcar #'gtk-forget-about-and delete-that-row old-value)
I think you can track down the existing observer for the kids slot of family to see what you would want to do. Both new and old values are /lists/ of kids, some new, some departing, so you need to call set-difference in each direction to find ones to add/delete on the gtk side. or...
(mapcar #'not-to-be old-value)) ;; would i need that?
No, that gets called by the existing kids observer on the family class, which is also why calling it yourself in a rule would be unnecessary (and a bad idea because it might be a whisker too soon). But you have me thinking, why reinvent the sorting into new/lost done by the existing kids observer? You can just add :after (:before?) methods on md-awaken/not-to-be to add/delete on the gtk side. That means two methods instead of one observer, but it seems more elegant/accurate.
Help with this one is really appreciated, because I feel I have never quite understood how to handle making instances in a cells slot properly (I how to clean up properly).
One of the first things to impress me about Cells was that it was relatively easy to handle things joining and exiting the model, but it is definitely and literally an "edge" case (I think of the overall model population expanding and contracting.) Cells3 got created precisely because that luck ran out: Cells internals started finding themselves operating on things that had been officially removed from the model, because of delicate timing issues -- ISTR it had to do with processing already "queued up" for an instance on the stack running after some code decided the instance should go away. I ended up with code all over the map to watch out for "dead" instances and ignore them. Interestingly, it was my design for the RoboCup competition that broke things, and I had written massive amounts of Cells code before then without a problem. Funny how that works.
If you dig out cells-manifesto.txt from the latest Cells CVS, in there you will find a semi-formal definition of dataflow integrity enforced by Cells3. That unfortunately requires a little less transparency when one is modifying model state from within an observer, but it makes models more robust.
The newest Cells, btw, generalizes the kids slot to allow one to specify any slot as "owning". (I think that is what I called it.) In fact, the new kids observer might not do the set-difference thing, i think that is now being done in the internals for any slot value change to an "owning" slot. (It goes by slot, not by rule.)
btw, if I sound fuzzy on Cells, that's the good news, I do not have to mess with it much any more. :)
As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row. You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o: (def-family-observer my-tree (<def options?>) slot-1 slot-2)
Left unsaid is that def-family-observer expands into:
(defmodel my-tree (family-observer) <slot defs for slot-1 and slot-2> (:default-initargs :slot-1 (c? (slot-1 (md-value self))) :slot-2 <same>))
...and observers for slot-1 and slot-2 specialized on my-tree to relay changes to gtk.
Cool. Gotta love lisp, macros, and cells. I wonder how many lines of C that would make.
:) I don't know, I used to do some pretty sick things with the C preprocessor (and before that the cobol copy-replacing).
As to the current status, I'm messing with CFFI to get some more bookkeeping deferred to the GTK side. Once you get started there's a function of everything :)
Yes, clearly a mature product. Good idea to let GTk handle as much as possible.
kt
On Wed, 12 Dec 2007 13:27:06 +0100, Ken Tilton kennytilton@optonline.net wrote:
Ken Tilton wrote:
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.
Roughly (cuz of rough recall of Cells2):
(defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k)))))))
Thanks! The following does the trick (incl. some rewriting)
:kids (c? (the-kids ; follow changes of our source (when (^md-value) ;; not sure why not (mapcar #'(lambda (k) (make-instance 'family-observer :md-value k)) (kids (^md-value))))))))
That handles rows in/out.
Actually, I don't quite see how it handles rows out. Where do I put stuff to properly clean out the old kids?
Can I do something like (c? (mapcar #'not-to-be (^kids)) (the-kids ...))) ? (looks wrong)
As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row.
That's easier, because the number is constant. So a simple def-c-output will do.
You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o:
(def-family-observer my-tree (<def options?>) slot-1 slot-2)
Yep. Thought of something like this. My plan was to supply a generic function for making child observers like
(def-f-o my-obs (#'mk-observer) slot-1 slot-2)
then the :kids cell will not call plain make-instance, but mk-observer, which can specify on the source, so if you have a mixed family of people and dogs
(def-f-o person-obs (#'mk-observer) name age) (def-f-o dog-obs (#'(lambda (&rest initargs) (apply #'make-instance 'dog-obs initargs)) race favorite-ball)
(defmethod mk-observer ((self person) &rest initargs) (apply #'make-instance 'person-obs self initargs))
(defmethod mk-observer ((self dog) &rest initargs) (apply #'make-instance 'dog-obs initargs))
Or simply
(def-f-o person-obs (person) name age) (def-f-o dog-obs (dog) race favorite-ball)
Expansion left as an exercise. :)
It is not inconceivable to have f-o link dynamically to any cell-mediated slot of the model instances, btw.
Is there some cells hook to get the list, or would that involve messing with MOP?
Peter
kt
-
Ken Tilton -
Peter Hildebrandt