Quoting Ian Ward (2012-10-13 14:47:04) > On Fri, Oct 12, 2012 at 6:23 PM, Patrick Totzke <[email protected]> > wrote: > > 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.
So the ListBox is a special kind of Pile in fact? I know that Pile can be of type Flow and List can't. But conceptually, where is the difference apart from that ListBox may display only a part of its list? What does Pile do if there is too little space for its entire content? (Why do these widgets not share more code)? > 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. I agree that It'd be ugly to put yet another feature into ListBox. But I have no good intuition how to place ListBox into some nice inheritance structure that also contains Pile and TreeBox ATM. Certainly those three widgets have a lot in common and thus should share code. > 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. I don't like this idea to be honest. Its not much different from making TreeBox a WidgetWrap'ed ListBox, adding some padding to the left in each line. In fact, *this* would be the easy way to come up with a Widget for displaying TreeWalker. Maybe I'll build this as a short term solution. But its not pretty. I'd like to keep the Walkers semantical objects only: no decorations, no info on folding. In my opinion these Walkers form some topology that one can explore by means of a TreeBox-Widget that defines the way one sees and moves in the structure. </metaphermode> turning to your other mail... Quoting Ian Ward (2012-10-13 15:10:55) > On Sat, Oct 13, 2012 at 7:22 AM, Patrick Totzke <[email protected]> > wrote: > > - 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. see above: I think letting walkers produce decorations is a bad idea. My current working idea for the "easy fix" wrap-a-listbox TreeBox is to let this TreeBox maintain a default value if a newly added widget is unfolded or not. And a list of positions that deviate from this default because the user manually toggled them. > > - 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. shouldn't it be "_calculate_visible" then? go for consistency :) > Horizontal scrolling means the widgets in the ListBox would have to be > fixed widgets not flow widgets. Yes, agreed: this is problematic. Maybe there should be some complement method of `pack` (that if i understand correctly computes the most compact way one can display the widget), namely one method that returns the size of the widget if one gives it as much horizontal space as it wants. For Text for instance, this would return the maximal length of any contained text line. One had to ensure that all basic widgets return a finite value here. then this would propagate to higher level containers. > 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 :-) How about having some widget that can display iclipped Canvases? > > - 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 Do I understand correctly that this returns the position of the "keyboard input cursor" of the terminal whithin the Widget? It's got nothing to do with the mouse coursor yes? > > - 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 I agree with the concept that a Widget itself has no size and can be rendered on a Canvas in different sizes. This means that whenever you want to `render`, you need to provide a size, OK. But i fail to see why one would ever need that size while reacting to input. I get some input, i make some internal changes, if these trigger changes that need to be made visible, then i trigger a 'modified' signal (or sth similar) and this in turn will result in the Mainloop re-rendering this Widget and *then* will provide the necessary dimension to `render`. Maybe I'm not seeing something obvious here but `keypress` itself should not need that parameter right? > > - 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 whoops, overlooked that, thanks! thats it for now, talk to you on #urwid, /p
signature.asc
Description: signature
_______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
