[Urwid] Rendering standout attribute across entire Columns widget

Jacob Courtneay jacob at sporkexec.com
Fri Sep 2 02:04:57 EDT 2011

Ian Ward <ian <at> excess.org> writes:
> Interesting change.  I think that moving to a slightly more CSS-like
> display attribute system might be clearer and easier to use though.
> Also in this specific case you can't add strings to AttrSpec instances
> (which sometimes are used as display attributes)
> How about this:
> 1. Canvases would start remembering the order that display attributes
> were applied
> eg:
>     w1 = Text(('first', ('second', "Hello")))
>     w2 = AttrMap(Text(('first', "Hello")), {'first':'second'})
> would both be widgets with display attributes applied to the "Hello"
> text in the order 'first', 'second'.
> 2. Screen palette lookups would match tuples of display attributes in
> order from last to first, stopping when no further match is found.
> eg:
>     palette = [('first', 'yellow', 'black'),
>                ('second', light blue', 'black')]
> would colour "Hello" light blue as it does now, but:
>     palette = [('first', 'yellow', 'black'),
>                ('second', light blue', 'black'),
>                (('first', 'second'), 'dark green', 'black')]
> would colour "Hello" dark green. Note that if there was another display
> attribute applied earlier:
>     w3 = Text(('zeroth', ('first', ('second', "Hello"))))
> The "Hello" text would still be dark green because ('first', 'second')
> is the last match found in the palette.

So you just mean there doesn't need to be a full match in the palette, 
right? It matches the longest possible chain. That would be pretty intuitive.

> This should cleanly solve the common "in focus" case.

I don't understand. If you mean it helps make focus attributes less special, 
that sounds good. Having to pass a second dict into AttrMap is kind of 
annoying, it seems like there could be a standard way of saying "this 
display attribute when it's focused".

> It doesn't go as far as allowing arbitrary combinations like adding
> standout to any display attribute.  You could do that with a list
> comprehension in the palette definition, similar to the "prefix."+attr
> case you site above.

Forcing the user to resort to that seems sort of clumsy. Is adding an 
attribute option (bold, standout, etc) to AttrSpec feasible? It looks tricky 
but mostly in display_common.py. That file scares me.

Finally, would performance be an issue for large palettes? Currently palette 
lookups with raw_display.Screen._pal_escape are fast dictionary lookups. Every 
lookup would now be required to check the entire palette unless it finds an 
exact match. Maybe this isn't a problem, I'm just speculating at this point.

I like the idea, it's much simpler to use. As for the implementation, would 
this involve CompositeCanvas.fill_attr_apply to remember attributes (similar 
to what I've already done) or something else? I'm not likely to be much help 
if the canvas changes are lower-level than that, but I can probably handle 
the screen attribute lookups, at least in raw_display.

-- Jacob

More information about the Urwid mailing list