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

[Ian Ward]

I've CC'd Thomas Dickey on this discussion because I hope he'll gently
put me in my place if I'm wrong about anything related to terminals,
terminfo and ncurses. (posting to the list is subscriber-only)

Derek Peschel wrote:
> 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 
>> 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.

I just meant that right now the python curses library raises an
exception if you try to use more colours than what the curses library
thinks it has, as your patch would for users whose terminfo entries say
"8 colours" (almost everybody)

>> 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.

Yes it is.  The real fly in the ointment is that, as far as I can tell,
there is no reliable way to tell what features a user's terminal really
supports.

In general, users have a TERM setting that exists in the terminfo
database, but the capabilities in the database do not give a complete
picture of the actual features of a user's terminal.  As an example, you
had to create a custom terminfo file just to describe your operating
system's built-in terminal.  That is ridiculous.  It seems clear that
developers are just ignoring terminfo, or perhaps letting it describe 
the oldest possible set of escape sequences for a given terminal.

Many console applications have chosen a set of escape sequences that 
they need and send them directly.  With modern terminals this approach 
may be more reliable than using curses and terminfo.

This is part of the reason that I wrote the raw_display module.  It's
slower and uses more bandwidth, but it seems to work even if a user's
terminal settings are wrong.

> 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).

That is an interesting idea.  Maybe Urwid could provide a convenience
function that would read and write file like:
$HOME/.application_name/urwid_palette.cfg

...
> 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.

Right now Urwid tries to offer a common denominator for most terminals
out there.

In my raw_display module I decided to support 16-colour escape sequences 
in xterm because some of xterm's fonts look really bad when they are 
made bold.  Other features could be added to raw_display in a similar 
way, Urwid could conceivably store some information about terminals that 
have extra features..

On the other hand, people developing console applications may be more 
interested in writing programs that work in as many environments as 
possible than being able to use a few extra features only available in 
some terminals.

>> 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.

That is where I started with Urwid, my target was an IBM PC text mode
console.. That's why I never thought of combining those attributes with
colours.

The syntax I was thinking of would be something like:
('header',  ['white', 'underline'], 'dark blue', ['bold', 'underline'] )
so it would be backwards-compatible.

Ian