Subject: Re: [Summer of Code]Wide character support for curses
To: Thomas Dickey <firstname.lastname@example.org>
From: Ruibiao Qiu <email@example.com>
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.