[Urwid] The missing part of my last mail

[Ian Ward]

Rebecca Breu wrote:
> Zitat von Ian Ward <ian at excess.org>:
> 
>>It seems to work for me.  Maybe the version of Python you're running is
>>linked against the curses library, not the ncurses library.
> 
> Yeah, you are right:
> 
> KEY_RESIZE is missing in the curses.h on that machine. However, I'll handle
> that AttributeError. Except for resizing, all works OK then.

I think I'll just hard code the value it returns when linked against 
ncurses. Resizing still won't work when linked against the curses 
library, but at least it won't cause an error.

>>The raw_display module should work regardless of which curses is linked
>>against Python.
> 
> 
> It seems to me that raw_display is more reliable than the (n)curses stuff.
> I tried lots of different TERM types on different machines, and with
> curses_display I often got a scrambled console, or only black and white
> display. Or even worse, the program quitted with something like
> "Error opening terminal". Whereas with raw_display, things work almost
> always fine.

With the (n)curses library you need to choose a value for TERM that 
matches your terminal, otherwise you will likely have problems with your 
display.

The main reason I wrote raw_display was that I don't have any control 
over which version of curses the user's python interpreter is linked 
against. So, if a user is running a UTF-8 capable terminal but the 
ncurses library is the "narrow" version then I can't send UTF-8 data to 
their terminal.

The newer versions of the ncurses libraries are great, and if I do a 
rewrite in C then I might not need raw_display.

> At the moment I use curses_display by default, with the possibility to
> switch to raw_display via command line option. I wonder if I should just
> do it the other way round? Does raw_display have any disadvantages I'm not
> aware of?

Yes, raw_display should be slower than curses_display because it doesn't 
have the drawing optimizations provided by the curses library. 
raw_display doesn't use the termcap database to read the escape 
sequences supported by the user's terminal and instead relies on a 
subset of common escape sequences (this could be viewed as a good or a 
bad thing).  raw_display can't detect when a user is using a monochrome 
terminal and always uses colour.

> Ian, on the webpage you wrote
> 
>     "New raw_display module [...]
> 
>     Avoids use of bold text in xterm and gnome-terminal for improved
>     text legibility."
> 
> Well, when I use raw_display with TERM=xterm, all those colours that
> are otherwise displayed in bold style (white, yellow, light cyan etc)
> are then displayed in black (which is the default foreground colour). Mmh.
> I guess that's not what you intended?

You have to actually run in xterm or gnome-terminal with TERM=xterm for 
that to work :-)  What terminal did you try that in?

Ian