Subject: Re: [Summer of Code]Wide character support for curses
To: Ruibiao Qiu <ruibiao@arl.wustl.edu>
From: Thomas Dickey <dickey@radix.net>
List: tech-userlevel
Date: 06/26/2005 17:56:43
On Sun, Jun 26, 2005 at 04:50:59PM -0500, Ruibiao Qiu wrote:
> Mr. Dickey,
>
> Thanks for your quick response.
no problem.
> On Sun, 26 Jun 2005, Thomas Dickey wrote:
> >actually ncurses works on more platforms (with essentially the same
> >functionality on each).
>
> I guess replacing the NetBSD curses libraries entirely with ncurses (as in
> OpenBSD) is not a decision I can make :-) (But, on the other hand, Brett
> and Julian, could this be an option? :-)
( I doubt that would happen ;-)
> >Another complication which occurs to me at the moment is that most
> >applications would prefer reading a wide character.
>
> I will look more into some multi-column character input method applications
> (such as cxterm or xcin) to find out how they feed the encoding of wide
> characters to a terminal, and what does getchar() return. Thanks for
> bringing it up.
I'm not sure how many _curses_ applications read wide character data.
I modified dialog to do this, making it build against either narrow-
or wide-character curses. That seems to work fine in xterm (uxterm),
using cut/paste (input methods are something I've done little with).
http://invisible-island.net/dialog/
I've also been modifying lynx to do the same (but that's not as complete -
there are lots of complicated details to keep the other configurations
working).
> >I'm interested in the smaller- and faster-metrics...
> >I'd suggest a simple file-viewer
> >Multibyte input could be added to that (e.g., a search command using
> >winnstr to fetch data from the display). Testing it with data that has
> >nonspacing characters and data that uses double-width characters would
> >exercise the waddch() logic.
>
> It sounds like a good plan. Thanks.
no problem.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net