On Sat, Oct 13, 2012 at 7:22 AM, Patrick Totzke <[email protected]> wrote: > OK, turning to implementing a TreeBox, I have a few questions.. > We see that this would-be TreeBox will share a lot of code with ListBox, so > assuming I want to subclass ListBox, what do I have to overwrite?
My last reply says "don't do this" but I'll try to answer your questions anyway :-) > - keypress() needs to be able to deal with moving up and down the tree, > and (later) also to trigger folding of subtrees. Now I'm wondering if we could implement folding and unfolding in the decorations returned by the list walker. If they have a callback to the list walker they could update its focus and it in turn could notify the ListBox of the change with the its 'modified' signal. > - decorations will be drawn in `render`, which - this being a box widget - > takes a size-tuple and returns a Canvas of that size. So I need to overwrite > `render`. > > - calculate_visible: Not sure what exactly this does, but I'm sure this will > be more > complicated for trees than for lists: we want to be able to also scroll to > the left/right > when changing focus beacause otherwise we could only ever show trees of > bounded > depth if we choose to indent child nodes. > I do not understand the docstring of this method. please explain. > How does this relate to `make_cursor_visible`? calcualte_visible is really an internal thing. It figures out which widgets are visible in the ListBox given the current focus position, size and list walker content. Horizontal scrolling means the widgets in the ListBox would have to be fixed widgets not flow widgets. Having a way to display that sort of widget would be useful outside of just trees, and maybe should be a separate discussion. I've done some thinking about the best way to accomplish something like that with horizontal list boxes nested in a normal ListBox (this way we could have unbounded scrolling in all directions :-) > - get_cursor_coords: i presume this is for dealing with a mouse cursor? > If so, why is this done in this widget and not some lower one? > I mean the exact location of a mouse cursor on the screen is surely > something > that one directly gets from a Screen? This is just part of the widget API. See http://urwid.readthedocs.org/en/latest/reference/widget.html#urwid.Widget.get_cursor_coords > - set_focus_valign this is to position the visible area around the focussed > widget. > It needs to be overwritten for TreeBox as the visible area is now two > dimensional. > Whats the difference to `shift_focus` and why does the latter need to know > the size > of the whole TreeBox? One acts immediately and the other does the next time one of the normal widget APIs gets the "current" size. Remember widgets don't have a size: http://urwid.readthedocs.org/en/latest/manual/widgets.html#custom-widgets > - Do i need to overwrite/define `_contents` to ensure compatability with some > higher level > Box-container API? This should stay as it is, it already delegates to the list walker. The common container API is a poor way of dealing with ListBox contents anyway, it's just there for consistency. > - what does `ends_visible` return? I think I improved the docs for that one http://urwid.readthedocs.org/en/latest/reference/widget.html#urwid.ListBox.ends_visible > > - why does keypress need to know the size the widget is going to be displayed? > This is a more general question because I don't see why one could ever need > this for any Widget. Mentioned above. Widgets in Urwid don't have a size http://urwid.readthedocs.org/en/latest/manual/widgets.html#custom-widgets > Sorry to nitpick - its hard to understand other peoples code, especially > these complex widgets :) My pleasure! Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
