On Sat, Jul 21, 2012 at 2:27 PM, Aleksandr Miroslav <[email protected]> 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! Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
