On Fri, Oct 12, 2012 at 6:23 PM, Patrick Totzke <[email protected]> wrote: > Hi again! > > I have a proof of concept for the Walker classes. So far we lack a > complementary > TreeBox widget to display structures represented by these though. > > You can find the code here: https://github.com/pazz/urwidtrees > > These Walkers are compatible with the current ListWalker API; > In fact, the provided examples work by passing them on to a ListBox, > that displays all nodes of the trees in depth-first order.
Very nice. > Quoting Ian Ward (2012-10-09 23:29:27) >> On Mon, Oct 8, 2012 at 10:48 AM, Patrick Totzke <[email protected]> >> wrote: >> Currently TreeListBox adds 'home'/'end' handling, which really should >> apply to any ListBox. The new List Walker API supports use of a >> "positions" method that returns an iterable that could be used for >> this purpose in the normal ListBox widget: > > I see. Not sure if this makes sense for trees, but it could be easily added > based on > get_next/prev. We'll defer this for now. [...] >> > 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 >> > https://github.com/pazz/alot/blob/master/extra/themes/screenshots/solarized.thread.png?raw=true) >> > 09:06:07 <pazz> or these folding icons from the current implementation. >> > all optional, including >> > indentation (sth i need for my app).. >> >> Fancy widget decorations could be generated from the TreeWalker. > > aye! > >> Maybe a decoration function that is passed the widget, the depth and >> any other information that might be useful for drawing little arrows >> and such could be defined. The default could just return >> Padding(widget, 'left', ('relative, 100), left=depth*2) or something. > > I think it should be the TreeBox responsible for the construction of any kind > of > decoration and not the Walker itself. I want to be able to display the same > walker > with or without indentation and so on.. This is a great point. Decoration of a tree and the actual structure of the tree are separate concerns. Adding decorations to a ListBox subclass wouldn't be the way to go, though. ListBox is responsible for displaying, scrolling, and passing focus and the cursor position between widgets stacked vertically. It's already the most complicated widget in the library, adding a feature that decorates widgets that come from a list walker (or tree walker) doesn't fit. Here's another idea: do the decoration in a ListWalker subclass that takes a tree walker object which only implements tree operations (not a superclass or subclass of ListWalker). This way we can mix and match different types of trees and different decorations. Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
