[Urwid] Rendering standout attribute across entire Columns widget

Jacob Courtneay jacob at sporkexec.com
Sat Sep 3 01:25:58 EDT 2011

Ian Ward <ian <at> excess.org> writes:

> Yes, so one way to do that would be AttrMap(foo, {}, {'*': 'focus'})

I notice that using this pattern, you'll be applying {'*': 'focus'} to each
bottom-level widget that needs a focus attribute. This seems a bit redundant.
Sufficiently complex layouts will probably apply a focus attribute to several 
widgets at once anyways, much like my case at the start of this thread, so it 
won't matter too much in practice.

> >> 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.
> Sure it's feasible, but except for standout it's pretty useless.  Many
> terminals don't support bold or underline, so you can't add those and
> expect anything to happen.  Also foregrounds and backgrounds can't
> safely be changed independently.  You really need to have different
> definitions for these display attribute changes and the best place for
> that is in the palette.

I was under the impression that foregrounds, backgrounds, and attributes were 
independently adjustable. Cascading (CSS-like) attributes don't sound feasible.
One less thing to worry about...

> > Finally, would performance be an issue for large palettes? Currently palette 
> > lookups with raw_display.Screen._pal_escape are fast dictionary lookups. Eve
> > 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.
> It would increase lookups to a worst case of (longest chain match)+1.
> Still a constant in any situation I can imagine, so I'm not worried. 

Oh, you can just try (n, n-1, ..., 1), then (n-1, n-2, ..., 1), and so on.
Not a problem at all! =)

> > 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.
> Yes, the change would be there and also in the Text markup processing.
> Currently the innermost display attribute simply replaces the others.
> Ian

About the Text markup, could you explain the utility of allowing arbitrary
attribute depth? For example:
>     w3 = Text(('zeroth', ('first', ('second', "Hello"))))
I can see why 'first' and 'second' might be useful, but when would anybody nest
attributes more than two deep?

...and I've got to stop using the web interface for this. The forced 80-column 
limit means I've got to reformat 79 and 80 column lines when quoted.

-- Jacob

More information about the Urwid mailing list