On Mon, Feb 17, 2014 at 10:04 AM, Vlad <[email protected]> wrote: > Over the course of building this app I noticed something that might be a bug > or "user error": > > - contrary to the documentation, AttrMap does not appear to forward method > calls to 'w', the wrapped widget.
Oh, you're absolutely right. There is a bug in the documentation. I decided that it was a mistake for AttrWrap to pass all attribute access and method calls to the wrapped class and I deliberately did not include that feature in AttrMap. It seems I forgot to update the docstring. There are many type of decoration widgets in Urwid. If we pass through attribute access for just one decoration, why not do it for all decorations? If we do it for all decorations then users will be able to mostly pretend the decorations aren't there, but that could lead to some really hard to understand code. It mixes the namespace of every decoration with the base widget's namespace. > I find AttrMap to be a very useful design concept. But I think it falls > short of its intended purpose because I find myself constantly needing to > insert .base_widget in various places -- AttrMap is not as transparent as the > docs suggest. A piece of urwid code will work but later break when you add > an extra AttrMap layer somewhere. Note that using AttrWrap instead makes the > example above work -- even though AttrWrap is deprecated in favor of AttrMap. > Several stock urwid examples also break if AttrWrap is replaced with > AttrMap, and it originally took me a few hours to figure out why. I agree that it should be easier to work with decoration widgets. The best idea I have at the moment is to add a 'decorations' property or 'get_decorations()' method to widgets that will be called whenever that widget is added to a container or assigned to loop.widget. This way a widget class can define all its own decorations but still present just its methods and attributes to the programmer. How does that approach sound to you? Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
