On Sun, Jun 26, 2005 at 12:53:18AM -0500, Ruibiao Qiu wrote:
> Hi all
> 
> I am pleased to announce that my proposal for a new NetBSD curses libraries 
> with wide character support was approved by Google for its first Summer of 
> Code program (http://code.google.com/summerofcode.html).

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.
 
>     * Design: 6/24 - 6/30 (10 hours);

that's a bit optimistic, unless you're not planning to make it compatible
with X/Open.

>     * Coding: 7/1 - 7/18 (25 hours);
>     * Testing: 7/19 - 8/7 (25 hours);
>     * Reporting and documentation: 8/8 - 8/14 (10 hours);
> - Motivation:
>   The NetBSD curses library currently does not support wide characters, 
>   which
>   makes it unsuitable for internationalization. The X/Open Curses Reference
>   gives more details about the wide characters for internationalization.
>   Although the GNU Ncurses package can be used as an installed package to
>   support wide characters, it is not part of the NetBSD source distribution,
>   and thus is limited for certain applications, such as installation 
>   scripts.
>   In addition, the Ncurses use more resources and may run slowly on some
                             ^^^ (than what?)

>   platforms with limited resource and processing capability (such as vax and
>   m68k).  Therefore, a fast NetBSD curses implementation with small memory
>   footprint is highly desirable. We need to modify the NetBSD curses 
>   libraries
>   to support wide characters for internationalization.

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.  For example,
moving nonspacing characters out to a separate structure means that all of
the refresh() logic would have to be revised to compare one cell at a time,
rather than a line at a time.

None of the mailing list comments touched on the hard parts, nor does this:

	http://www.arl.wustl.edu/~ruibiao/SoC/NetBSD-curses/

(for instance, input is not mentioned).

Looking forward to the benchmarking results which you'll publish in October.
(bye)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net