hackguide.html

ncurses 库 可能有用酒用 没用就算了 我觉得还可以用

interfaces to a small set of basic functions and data structures used
to manipulate the virtual screen (in particular, none of this code
does any I/O except through calls to more fundamental modules
described below).  The files
<blockquote>
<CODE>
lib_addch.c
lib_bkgd.c
lib_box.c
lib_chgat.c
lib_clear.c
lib_clearok.c
lib_clrbot.c
lib_clreol.c
lib_colorset.c
lib_data.c
lib_delch.c
lib_delwin.c
lib_echo.c
lib_erase.c
lib_gen.c
lib_getstr.c
lib_hline.c
lib_immedok.c
lib_inchstr.c
lib_insch.c
lib_insdel.c
lib_insstr.c
lib_instr.c
lib_isendwin.c
lib_keyname.c
lib_leaveok.c
lib_move.c
lib_mvwin.c
lib_overlay.c
lib_pad.c
lib_printw.c
lib_redrawln.c
lib_scanw.c
lib_screen.c
lib_scroll.c
lib_scrollok.c
lib_scrreg.c
lib_set_term.c
lib_slk.c
lib_slkatr_set.c
lib_slkatrof.c
lib_slkatron.c
lib_slkatrset.c
lib_slkattr.c
lib_slkclear.c
lib_slkcolor.c
lib_slkinit.c
lib_slklab.c
lib_slkrefr.c
lib_slkset.c
lib_slktouch.c
lib_touch.c
lib_unctrl.c
lib_vline.c
lib_wattroff.c
lib_wattron.c
lib_window.c
</CODE>
</blockquote>
are all in this category.  They are very
unlikely to need change, barring bugs or some fundamental
reorganization in the underlying data structures. <P>

These files are used only for debugging support:
<blockquote>
<code>
lib_trace.c
lib_traceatr.c
lib_tracebits.c
lib_tracechr.c
lib_tracedmp.c
lib_tracemse.c
trace_buf.c
</code>
</blockquote>
It is rather unlikely you will ever need to change these, unless
you want to introduce a new debug trace level for some reasoon.<P>

There is another group of files that do direct I/O via <EM>tputs()</EM>,
computations on the terminal capabilities, or queries to the OS
environment, but nevertheless have only fairly low complexity.  These
include:
<blockquote>
<code>
lib_acs.c
lib_beep.c
lib_color.c
lib_endwin.c
lib_initscr.c
lib_longname.c
lib_newterm.c
lib_options.c
lib_termcap.c
lib_ti.c
lib_tparm.c
lib_tputs.c
lib_vidattr.c
read_entry.c.
</code>
</blockquote>
They are likely to need revision only if
ncurses is being ported to an environment without an underlying
terminfo capability representation. <P>

These files
have serious hooks into
the tty driver and signal facilities:
<blockquote>
<code>
lib_kernel.c
lib_baudrate.c
lib_raw.c
lib_tstp.c
lib_twait.c
</code>
</blockquote>
If you run into porting snafus
moving the package to another UNIX, the problem is likely to be in one
of these files.
The file <CODE>lib_print.c</CODE> uses sleep(2) and also
falls in this category.<P>

Almost all of the real work is done in the files
<blockquote>
<code>
hardscroll.c
hashmap.c
lib_addch.c
lib_doupdate.c
lib_getch.c
lib_mouse.c
lib_mvcur.c
lib_refresh.c
lib_setup.c
lib_vidattr.c
</code>
</blockquote>
Most of the algorithmic complexity in the
library lives in these files.
If there is a real bug in <STRONG>ncurses</STRONG> itself, it's probably here.
We'll tour some of these files in detail
below (see <A HREF="#engine">The Engine Room</A>). <P>

Finally, there is a group of files that is actually most of the
terminfo compiler.  The reason this code lives in the <STRONG>ncurses</STRONG>
library is to support fallback to /etc/termcap.  These files include
<blockquote>
<code>
alloc_entry.c
captoinfo.c
comp_captab.c
comp_error.c
comp_hash.c
comp_parse.c
comp_scan.c
parse_entry.c
read_termcap.c
write_entry.c
</code>
</blockquote>
We'll discuss these in the compiler tour.

<H2><A NAME="engine">The Engine Room</A></H2>

<H3><A NAME="input">Keyboard Input</A></H3>

All <CODE>ncurses</CODE> input funnels through the function
<CODE>wgetch()</CODE>, defined in <CODE>lib_getch.c</CODE>.  This function is
tricky; it has to poll for keyboard and mouse events and do a running
match of incoming input against the set of defined special keys. <P>

The central data structure in this module is a FIFO queue, used to
match multiple-character input sequences against special-key
capabilities; also to implement pushback via <CODE>ungetch()</CODE>. <P>

The <CODE>wgetch()</CODE> code distinguishes between function key
sequences and the same sequences typed manually by doing a timed wait
after each input character that could lead a function key sequence.
If the entire sequence takes less than 1 second, it is assumed to have
been generated by a function key press. <P>

Hackers bruised by previous encounters with variant <CODE>select(2)</CODE>
calls may find the code in <CODE>lib_twait.c</CODE> interesting.  It deals
with the problem that some BSD selects don't return a reliable
time-left value.  The function <CODE>timed_wait()</CODE> effectively
simulates a System V select.

<H3><A NAME="mouse">Mouse Events</A></H3>

If the mouse interface is active, <CODE>wgetch()</CODE> polls for mouse
events each call, before it goes to the keyboard for input.  It is
up to <CODE>lib_mouse.c</CODE> how the polling is accomplished; it may vary
for different devices. <P>

Under xterm, however, mouse event notifications come in via the keyboard
input stream.  They are recognized by having the <STRONG>kmous</STRONG> capability
as a prefix.  This is kind of klugey, but trying to wire in recognition of
a mouse key prefix without going through the function-key machinery would
be just too painful, and this turns out to imply having the prefix somewhere
in the function-key capabilities at terminal-type initialization. <P>

This kluge only works because <STRONG>kmous</STRONG> isn't actually used by any
historic terminal type or curses implementation we know of.  Best
guess is it's a relic of some forgotten experiment in-house at Bell
Labs that didn't leave any traces in the publicly-distributed System V
terminfo files.  If System V or XPG4 ever gets serious about using it
again, this kluge may have to change. <P>

Here are some more details about mouse event handling: <P>

The <CODE>lib_mouse()</CODE>code is logically split into a lower level that
accepts event reports in a device-dependent format and an upper level that
parses mouse gestures and filters events.  The mediating data structure is a
circular queue of event structures. <P>

Functionally, the lower level's job is to pick up primitive events and
put them on the circular queue.  This can happen in one of two ways:
either (a) <CODE>_nc_mouse_event()</CODE> detects a series of incoming
mouse reports and queues them, or (b) code in <CODE>lib_getch.c</CODE> detects the
<STRONG>kmous</STRONG> prefix in the keyboard input stream and calls _nc_mouse_inline
to queue up a series of adjacent mouse reports. <P>

In either case, <CODE>_nc_mouse_parse()</CODE> should be called after the
series is accepted to parse the digested mouse reports (low-level
events) into a gesture (a high-level or composite event).

<H3><A NAME="output">Output and Screen Updating</A></H3>

With the single exception of character echoes during a <CODE>wgetnstr()</CODE>
call (which simulates cooked-mode line editing in an ncurses window),
the library normally does all its output at refresh time. <P>

The main job is to go from the current state of the screen (as represented
in the <CODE>curscr</CODE> window structure) to the desired new state (as
represented in the <CODE>newscr</CODE> window structure), while doing as
little I/O as possible. <P>

The brains of this operation are the modules <CODE>hashmap.c</CODE>,
<CODE>hardscroll.c</CODE> and <CODE>lib_doupdate.c</CODE>; the latter two use
<CODE>lib_mvcur.c</CODE>.  Essentially, what happens looks like this: <P>

The <CODE>hashmap.c</CODE> module tries to detect vertical motion
changes between the real and virtual screens.  This information
is represented by the oldindex members in the newscr structure.
These are modified by vertical-motion and clear operations, and both are
re-initialized after each update. To this change-journalling
information, the hashmap code adds deductions made using a modified Heckel
algorithm on hash values generated from the line contents. <P>

The <CODE>hardscroll.c</CODE> module computes an optimum set of scroll,
insertion, and deletion operations to make the indices match.  It calls
<CODE>_nc_mvcur_scrolln()</CODE> in <CODE>lib_mvcur.c</CODE> to do those motions. <P>

Then <CODE>lib_doupdate.c</CODE> goes to work.  Its job is to do line-by-line
transformations of <CODE>curscr</CODE> lines to <CODE>newscr</CODE> lines.  Its main
tool is the routine <CODE>mvcur()</CODE> in <CODE>lib_mvcur.c</CODE>.  This routine
does cursor-movement optimization, attempting to get from given screen
location A to given location B in the fewest output characters posible. <P>

If you want to work on screen optimizations, you should use the fact
that (in the trace-enabled version of the library) enabling the
<CODE>TRACE_TIMES</CODE> trace level causes a report to be emitted after
each screen update giving the elapsed time and a count of characters
emitted during the update.  You can use this to tell when an update
optimization improves efficiency. <P>

In the trace-enabled version of the library, it is also possible to disable
and re-enable various optimizations at runtime by tweaking the variable
<CODE>_nc_optimize_enable</CODE>.  See the file <CODE>include/curses.h.in</CODE>
for mask values, near the end.

<H1><A NAME="fmnote">The Forms and Menu Libraries</A></H1>

The forms and menu libraries should work reliably in any environment you
can port ncurses to. The only portability issue anywhere in them is what
flavor of regular expressions the built-in form field type TYPE_REGEXP
will recognize. <P>

The configuration code prefers the POSIX regex facility, modeled on
System V's, but will settle for BSD regexps if the former isn't available. <P>

Historical note: the panels code was written primarily to assist in
porting u386mon 2.0 (comp.sources.misc v14i001-4) to systems lacking
panels support; u386mon 2.10 and beyond use it.  This version has been
slightly cleaned up for <CODE>ncurses</CODE>.

<H1><A NAME="tic">A Tour of the Terminfo Compiler</A></H1>

The <STRONG>ncurses</STRONG> implementation of <STRONG>tic</STRONG> is rather complex
internally; it has to do a trying combination of missions. This starts
with the fact that, in addition to its normal duty of compiling
terminfo sources into loadable terminfo binaries, it has to be able to