search

urwid / urwid

Console user interface library for Python (official repo)
urwid.org
GNU Lesser General Public License v2.1
2.81k stars 315 forks source link

Set background for a widget container #329

Open BkPHcgQL3V opened 5 years ago

BkPHcgQL3V commented 5 years ago

Is it possible to set only the background color of a Pile or Columns widget, so that it is applied to all its children?

I found AttrMap, but it seems that it can only override foreground and background simultaneously.

The goal is to change the background color of many widgets, which have many different foreground colors. The only way to achieve this that I found is to declare a copy of every attribute used the widgets in the palette, then use e.g. AttrMap to switch to that version.

mhils commented 4 years ago

To add a practical use case: We have a HTTP request list in mitmproxy which makes heavy use of colors to display various attributes. We have about 30 palette entries just for this:

image

This interface makes it hard to see which row is currently selected. Ideally, we'd want a soft row highlight as requested in mitmproxy/mitmproxy#3732:

image

Right now, this would mean we'd have to make every single element in our rendering logic focus-aware and duplicate all palette styles with a slightly different background. This is just one example for which id would be very useful to us to have a more powerful styling model in urwid.

ribosomerocker commented 4 years ago

I'm with you here. I've been looking for a way to set a global background of the screen to something like dark magenta but I can not find any way in the documentation nor in the examples that would help

tonycpsu commented 4 years ago

I could have sworn there was an issue for this already, but maybe I'm just thinking back to some discussions over IRC a while ago.

Yeah, something more CSS-like that treats foreground, background, and decorations separately would be a welcome addition. I've often ended up doing the same "generate palette entries for every combination of m foreground colors and n background colors, and it ain't pretty.

Seems like a significant chunk of work, though, that would touch on a lot of different modules -- palette, AttrMap, text markup... If I were to attack this, I'd strongly consider writing a whole new model for hierarchical styling from the ground up and make it non backwards-compatible for a 3.0.0 release or something.