Subject: Re: [Summer of Code]Wide character support for curses
To: Thomas Dickey <>
From: Ruibiao Qiu <>
List: tech-userlevel
Date: 06/26/2005 14:19:14
Hello, Mr. Dickey

I am really glad that you can offer some expert advice as a long-time GNU 
ncurses developer and maintainer.

On Sun, 26 Jun 2005, Thomas Dickey wrote:
> That's interesting.  As I read the faq, and compare with your resume,
> I have to conclude that you did not actually graduate last month,
> since that would have disqualified you for this program.

Right.  I will finish up this summer.  Good observation :-)

>>     * Design: 6/24 - 6/30 (10 hours);
> that's a bit optimistic, unless you're not planning to make it compatible
> with X/Open.

This is just an estimated schedule.  I will spend the next week on design 
document.  Your feedback and comments are highly appreciated.

>>   In addition, the Ncurses use more resources and may run slowly on some
>                             ^^^ (than what?)

Sorry about my English. I thought ``Ncurses'' is plural.  Thanks for pointing 

What I wanted to say is that many believe that ncurses (with its rich set of 
features) consumes more resources than NetBSD's striped down version of curses 
libraries that works on as many platforms as possible.

> Aside from the comment about possibly splitting off nonspacing characters
> into a separate data structure, there's probably no way to reduce the memory
> needed.  However that would also add complexity (and without appreciably
> more design effort than one day), is likely to run more slowly.

I will carefully look into this option, and study the time and space tradeoff 
of different implementations in the design document.

> None of the mailing list comments touched on the hard parts, nor does this:
> (for instance, input is not mentioned).

Could you be more specific about the hard parts based on your ncurses 
development experience?  That will be very valuable to our project.

I did look into the input routines, but I thought there is no major changes 
needed there.  It uses getchar() to get input characters from input, does 
multi-character assembling, and calls waddch() for echo.  I will revisit this 
during the design phase.

> Looking forward to the benchmarking results which you'll publish in October.

I would highly appreciate it if you suggest some specific tests that we should 
include in our benchmark tests.  Thanks.