Re: [Tile-dev] Strawman Tree widget API

[Brett S. <bre...@ya...>]

--- Joe English <jen...@fl...> wrote:

> 
> Brett Schwarz  wrote:
> 
> > [Joe English]
> > > I'm not sure how useful user-supplied node IDs
> are [...]
> > 
> > One thing I use explicit node names for is so that
> I
> > can identify the node during callbacks (i.e. when
> > selected). Think of it as "client data" in the
> node
> > name. I'm not sure if this is the right way to do
> this
> > or not, but I find it comes in handy.
> 
> I often do the same thing myself -- often times the
> data
> displayed in the tree comes from some other source
> that has
> its own node identifiers; that's why I chose the
> BWidget
> syntax initially, so the tree widget identifiers
> match
> the source data identifiers.
> 
> On the other hand, just about as often the source
> data *doesn't*
> have any notion of a node identifier, so there's an
> extra burden 
> on the programmer to manufacture one.  This could
> just be a matter
> of using "#auto" and letting the Tree widget
> generate one, 
> but still...
> 
> > Of course, one
> > could just keep a reference to the node id
> (generated
> > from treeview) and client data in a separate
> > structure, but I kind of like keeping it together.
> 
> That's what you have to do when using the Canvas
> widget too.
> 
> On balance, I think the 2-argument form is
> preferable to
> the 3-argument one.  It's easier to use in the
> common case,
> simplifies the internals, reduces the number of
> error paths, 
> and saves a bit of memory.  I'm strongly leaning
> towards that 
> right now.
> 

ok, how about another option (I know, I know, not
another one). But maybe a clientdata option, so you
can leave clientdata for that node. Really haven't
thought it through, but I am still thinking that there
should at least be an option to associate data to that
node. Could be:

    -clientdata
or maybe more specifically
    -nodename

The latter might be preferred in the case of searhing
for certain nodes and/or testing for certain nodes.
(see below).

> 
> > One other thing that I think is missing, is a way
> to
> > find out if a node exists. In BWidgets, it would
> be:
> > 
> > $widget exists <nodename>
> 
> Would this still be useful if node IDs weren't
> user-supplied?
>
I guess not, but that's another reason to have
nodenames ;) 

Ok, here's one of the reasons I use $pathname exists
nodename. If I am dynamically generating the Tree
structure, I want to find out if the node already
exists (i.e. there might be duplicates), and maybe I
don't want to show duplicates.

Also, if I am dynamically generating nodes, and there
is a hierarchy, then I want to test to see if the
parent node exists first, before adding the child
node. If it exists, then add the child, if not, the
add the parent first:

if {[$path exists parentnode]} {
    $path insert end parentnode childnode ... [*]
} else {
    $path insert end root parentnode ...
    $path insert end parentnode childnode ...
}

Again, I could keep all this info in a separate
structure, but it just seems right to keep them
together...

    --brett


[*] or of course, it could be:
$path insert end parentnode -nodename childnode ...