[cells-gtk-devel] tree-view children

[Kenny Tilton]

ΜΑΡΓΙΟΥΛΑΣ ΒΑΣΙΛΕΙΟΣ wrote:

>Kenny Tilton wrote
>
>  
>
>>I have been poking around treebox and tree-view for 
>>a while, cannot spot anything. My guess, therefore, is that eventually 
>>we get a callback from Gtk which asks "what are the children of this 
>>object?". Then some GF is being dispatched on that object. So we have to 
>>find the callback and then the GF. My guess is that the ubiquitous 
>>"kids" slot is being sampled in this example, which would be a 
>>reasonable default for a Cells app. But I would expect an override (what 
>>"items-factory" sounds like but is not), so perhaps there is some GF 
>>which calls kids but can be overrode, or some other factory slot is 
>>being bound to #'kids.
>>    
>>
>
>gtk-tree-store-set-kids traverse family-kids hierarchy and sets tree-store 
>model.
>forcing :items to be of type family was propably a bad idea 
>
Well, not too bad looking at this:

> (defun gtk-tree-store-set-kids (model val-tree par-iter index 
> column-types items-factory &optional path)
>   (with-tree-iter (iter)
>     (gtk-ffi::gtk-tree-store-append model iter par-iter)
>     (gtk-ffi::gtk-tree-store-set model iter
>       column-types
>       (append
>        (funcall items-factory val-tree)
>        (list (format nil "(~{~d ~})" (reverse (cons index path))))))
>     (when (subtypep (class-name (class-of val-tree)) 'cells:family)
>       (loop for sub-tree in (cells:kids val-tree)
>           for pos from 0 do
>             (gtk-tree-store-set-kids model sub-tree iter
>               pos column-types items-factory (cons index path))))))


It looks as if we simply need to work in a GF (gtk-tree-kids?) 
specialized on Family and do some relatively trivial refactoring. Then 
if someone wants a different source of tree branches they simply 
specialize gtk-tree-kids on their class.

    (defmethod gtk-tree-kids ((self family)) (^kids))

and:
.....
    (loop for sub-tree in (gtk-tree-kids val-tree)....

kt