[cells-gtk-devel] tree-view children

[Peter Denno]

On Wednesday 02 February 2005 21:16, Kenny Tilton wrote:
> >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.

Agreed, I favor the latter also. In fact, I'd not use a GF but a user supplied 
function -- and thereby eliminate the overhead of identifying the effective 
method. But, a GF is an OK with me if that's what you guys want.

> >(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"? 

Poorly worded, wasn't it? 

I meant only what I just said above: that ideally the user would supply a 
function. Whether or not it names a GF or is regular function would be his 
business....You might also have an accessor on the slot referencing this 
function so that it can be changed to address different presentations.

The construction of the trees in my application takes about 15 seconds. But I 
don't know yet where the time is going. (Is it in calls to the child method 
or something else?)

> 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.

I like the cells concept, but there will always be places where for reasons of  
efficiency or just mismatch of design, it would be good to "have an out."  
Another place where I think I will need "an out" in my code is updating a 
progress bar: I check the size of a hash-table to determine the size of the 
progress bar. Its not the value in a cells slot that changes, (the value is 
always the same hash-table) it is the size of the table. And ideally I 
wouldn't update the bar after every write to the table -- that would be too 
often -- but maybe every 50 or 100. So maybe what I'd do here is use cells to 
start and stop the periodic (by timer timeout) invocation of a progress bar 
update process.

-- 
Best Regards, 
- Peter