[Urwid] redesigning the tree API

Patrick Totzke patricktotzke at gmail.com
Mon Oct 8 10:48:35 EDT 2012

Hi all,

some thoughts about $topic, as recently posted in #urwid:

08:52:27 <pazz> I stopped trying to improve this and started thinking about how the API *should* be. how 
                do you feel about the following:
08:58:42 <pazz> we introdude a TreeWalker, that depends on virtual methods get_[previous|next]_sibbling, 
                get_parent, and get_children, each getting one key. if you want to make anything usefull, 
                you must overwrite them, otherwise they default to "return None", which means that there 
                is nothing.
08:59:35 <pazz> based on this, we define get_[next|previous], that takes a key and returns the next key in 
                depth-first order.
09:00:29 <pazz> Now we introduce a TreeBox, that like ListBox works on a TreeWalker.
09:01:57 <pazz> In fact, we can now let ListBox derive from TreeBox, because a ListWalker is just a 
                TreeWalker that lets the get_[parent|children] methods untouched.
09:02:58 <pazz> now all the helper ListWalker classes can derive from TreeWalker directly, so that the API 
                for easy tasks don't change.
09:05:06 <pazz> all the fancy displaying magic goes into TreeWidget, for example the bars that indicate 
                the tree structure (see 
09:06:07 <pazz> or these folding icons from the current implementation. all optional, including 
                indentation (sth i need for my app).. 
09:07:32 <pazz> i don't know when i could spend the time to do this so i wanted to dump the idea here. if 
                you hate it i wouldn't go for it. if i don't find the time someone else might do the 
                right™ thing at some point..
09:09:54 <pazz> ...and by TreeWidget i meant TreeBox :)
09:13:14 <pazz> with this one could make the browse.py example super easy: one simply defines a 
                DirectoryWalker that implements the getter in all four directions that simply return a 
                Text(path). Then one hands this to a TreeBox; done.
09:17:15 <pazz> also, one could introduce something like SimpleListWalker for some fixed list structure 
                that defines a tree. A class that takes sth like {widget: w, children:[{widget:c1, 
                children:[...]}]} of fixed finite height and builds the corresponding TreeWalker
15:54:54 <wardi> pazz: design discussions might be better on the mailing list or wiki


More information about the Urwid mailing list