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