[Urwid] Patches to the library: more attributes and colors

[Derek Peschel]

On Mon, Jul 03, 2006 at 07:38:45AM -0400, Ian Ward wrote:
> This "osxterm" setting wouldn't be useful for people that haven't 
> installed your terminfo file, right?  Also, the change to curses will 

Right.  My changes are totally unpolished and specific to my system,
but I thought posting them would give people ideas and get me advice
about a direction to continue in.

> make Urwid crash on terminals that curses thinks only have 8 colours.

I assumed it would produce the wrong output, but why would it crash?
Because applications ask for colors that don't exist?  That's a matter of
application design as well as library design.

> Regarding the background colours, I did some testing with different 
> terminal emulators on my system and I found that support for 16 
> background colours is quite limited.  If I do add these colours I'm 
> worried that applications that use these colours will look really bad on 
> many user's terminals.

How would you solve that, or would you just ignore the problem?  Having
the application know which colors it wants, when terminals and user
tastes differ, seems to me to be a fundamental problem.

I've thought about some kind of preferences file that the register_palette
function looks in.  The file might contain sections for individual
applications or groups of them, and for individual terminals or groups
of them.  The file would override the application defaults.  The idea
reminds me of X (which is not entirely a good thing).

Another solution is to have the application and the library adapt to the
terminal.  The terminfo standard defines capabilities "colors" (integer,
max. number of colors usable at once), "pairs" (integer, max. number of
foreground/background combinations usable at once), "ncv" (integer, bit
mask of monochrome attributes that can't be used with colored text).
The curses C functions would check those, urwid would ask curses, and the
application would ask urwid.  Or you could bypass curses and create your
own terminal description format.  This solution doesn't handle user
preferences as the first one does.  It also means someone has to describe
each terminal correctly.

> Regarding the other attributes (bold, underline, etc) I have been 
> considering allowing them to be combined with regular foreground 
> attributes because they seem to work properly in most of the terminals I 
> have tested.

That would be useful.  Isn't a new syntax for palette entries needed
to allow old and new applications to work?  Also, I know designs
inspired by the PC video text modes (which don't allow underlining and
color, and don't distinguish bold from bright foreground) are still
quite common.

-- Derek