[cells-gtk-devel] tree-view children

[Kenny Tilton]

Peter Denno wrote:

>On Wednesday 02 February 2005 17:29, Kenny Tilton wrote:
>  
>
>>ΜΑΡΓΙΟΥΛΑΣ ΒΑΣΙΛΕΙΟΣ wrote:
>>    
>>
>>>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
>>    
>>
>
>Yeah, but is it really necessary for the things in the tree to be CLOS 
>objects, and subclasses of family? My trees have over 1000 objects in them. I 
>have been using structs. 
>
That is fine. You can specialize a method on the struct just as well as 
any CLOS class. As you did....

>
>I eliminated the test (when (subtypep (class-name (class-of val-tree)) 
>'cells:family) and wrote a method on cells:kids for my structs. Seems to 
>work. Am I violating the cells model by doing that? Will I pay a price later? 
>
Oh, I would break the Family-to- Gtk-tree thing once and for all by 
creating an API entry (gtk-tree-kids) and letting the Family class 
answer with KIDS, but let other things answer any way they like.

I think specializing KIDS as you did will work (haven't checked to see 
if I myself messed up and assumed somewhere that KIDS was only 
specialized on Family or its descendants) but that could happen eventually.

The way I attack close calls like this goes like this: do you really 
want your structures to behave like Family in some way, or do you just 
want gtk-trees to accept your non-Family structures? I see the latter as 
what is really going on, in which case gtk-trees are not justified in 
using KIDS to get the branches of a tree. gtk-trees should offer a GF 
which anyone can specialize to answer the branches question.

>(I don't know, I have 0 experience with this). If my approach is OK, it is 
>better (faster, more flexible) to allow the user to provide a children 
>function and not use cells:kids at all --- or allow cells:kids to be the 
>default if the child function isn't supplied.
>  
>
Sorry, did you mean to say "is it better"? Anyway, I say gtk-trees 
should not know about the Family class unnecesssarily (I have not 
checked to see if it already has some other dependencies). In which case 
the cells-gtk package should just support a gtk-trees-kids (or -branches 
or -children or -subtrees) call, provide a default method which returns 
nil, and let clients supply a callback as needed.

kt

-- 
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd