[Urwid] TreeNode vs ParentNode

Ian Ward ian at excess.org
Sat Jul 21 14:44:13 EDT 2012

On Sat, Jul 21, 2012 at 2:27 PM, Aleksandr Miroslav
<alexmiroslav at gmail.com> wrote:
> Now I have the question I originally wanted to ask:
> Why use a TreeNode at all? Why not use a ParentNode everywhere? The leaf
> nodes would then, instead of being TreeNodes, just be ParentNodes
> without any children.
> This way, if I wanted to add something to a leaf node, I can just simply
> add a child node to it, since it is already a ParentNode. Otherwise, I
> would have to convert the leaf node from a TreeNode to a ParentNode, and
> then add the child node.

Yes, I think I said as much in my first reply :-)

These "Node" classes were contributed earlier by someone that factored
them out of the browse.py example program.  That program has
directories and files it wants to display so the separate node classes
came from that.  Their interface is also complicated by the fact that
the browse.py nodes don't come into existence in a fixed order,
directories are read and nodes created dynamically as the user scrolls
or expands the list.

I don't see any strong reason to have the two different Node classes
at the moment.  I would accept a patch to make them the same
"TreeNode" class as long as the examples that use them don't break.

I might go even further.  Why have node objects at all?  The
TreeWIdget instances should be able to track their location in the
tree well enough.  There seems to be lots of duplicated logic between
that class and the "Node" classes.

Patches welcome!


More information about the Urwid mailing list