ncurses-intro.html

ncurses-5.4 需要的就来下把 一定会有用的哦

at the top of the program source.  The screen package uses the Standard I/O
library, so <CODE>&lt;curses.h&gt;</CODE> includes
<CODE>&lt;stdio.h&gt;</CODE>. <CODE>&lt;curses.h&gt;</CODE> also includes
<CODE>&lt;termios.h&gt;</CODE>, <CODE>&lt;termio.h&gt;</CODE>, or
<CODE>&lt;sgtty.h&gt;</CODE> depending on your system.  It is redundant (but
harmless) for the programmer to do these includes, too. In linking with
<CODE>curses</CODE> you need to have <CODE>-lncurses</CODE> in your LDFLAGS or on the
command line.  There is no need for any other libraries.

<H3><A NAME="updating">Updating the Screen</A></H3>

In order to update the screen optimally, it is necessary for the routines to
know what the screen currently looks like and what the programmer wants it to
look like next. For this purpose, a data type (structure) named WINDOW is
defined which describes a window image to the routines, including its starting
position on the screen (the (y, x) coordinates of the upper left hand corner)
and its size.  One of these (called <CODE>curscr</CODE>, for current screen) is a
screen image of what the terminal currently looks like.  Another screen (called
<CODE>stdscr</CODE>, for standard screen) is provided by default to make changes
on. <P>

A window is a purely internal representation. It is used to build and store a
potential image of a portion of the terminal.  It doesn't bear any necessary
relation to what is really on the terminal screen; it's more like a
scratchpad or write buffer. <P>

To make the section of physical screen corresponding to a window reflect the
contents of the window structure, the routine <CODE>refresh()</CODE> (or
<CODE>wrefresh()</CODE> if the window is not <CODE>stdscr</CODE>) is called. <P>

A given physical screen section may be within the scope of any number of
overlapping windows.  Also, changes can be made to windows in any order,
without regard to motion efficiency.  Then, at will, the programmer can
effectively say ``make it look like this,'' and let the package implementation
determine the most efficient way to repaint the screen.

<H3><A NAME="stdscr">Standard Windows and Function Naming Conventions</A></H3>

As hinted above, the routines can use several windows, but two are
automatically given: <CODE>curscr</CODE>, which knows what the terminal looks like,
and <CODE>stdscr</CODE>, which is what the programmer wants the terminal to look
like next.  The user should never actually access <CODE>curscr</CODE> directly.
Changes should be made to through the API, and then the routine
<CODE>refresh()</CODE> (or <CODE>wrefresh()</CODE>) called. <P>

Many functions are defined to use <CODE>stdscr</CODE> as a default screen.  For
example, to add a character to <CODE>stdscr</CODE>, one calls <CODE>addch()</CODE> with
the desired character as argument.  To write to a different window. use the
routine <CODE>waddch()</CODE> (for `w'indow-specific addch()) is provided.  This
convention of prepending function names with a `w' when they are to be
applied to specific windows is consistent.  The only routines which do not
follow it are those for which a window must always be specified. <P>

In order to move the current (y, x) coordinates from one point to another, the
routines <CODE>move()</CODE> and <CODE>wmove()</CODE> are provided.  However, it is
often desirable to first move and then perform some I/O operation.  In order to
avoid clumsiness, most I/O routines can be preceded by the prefix 'mv' and
the desired (y, x) coordinates prepended to the arguments to the function.  For
example, the calls

<PRE>
	  move(y, x);
	  addch(ch);
</PRE>

can be replaced by

<PRE>
	  mvaddch(y, x, ch);
</PRE>

and

<PRE>
	  wmove(win, y, x);
	  waddch(win, ch);
</PRE>

can be replaced by

<PRE>
	  mvwaddch(win, y, x, ch);
</PRE>

Note that the window description pointer (win) comes before the added (y, x)
coordinates.  If a function requires a window pointer, it is always the first
parameter passed.

<H3><A NAME="variables">Variables</A></H3>

The <CODE>curses</CODE> library sets some variables describing the terminal
capabilities.

<PRE>
      type   name      description
      ------------------------------------------------------------------
      int    LINES     number of lines on the terminal
      int    COLS      number of columns on the terminal
</PRE>

The <CODE>curses.h</CODE> also introduces some <CODE>#define</CODE> constants and types
of general usefulness:

<DL>
<DT> <CODE>bool</CODE>
<DD> boolean type, actually a `char' (e.g., <CODE>bool doneit;</CODE>)
<DT> <CODE>TRUE</CODE>
<DD> boolean `true' flag (1).
<DT> <CODE>FALSE</CODE>
<DD> boolean `false' flag (0).
<DT> <CODE>ERR</CODE>
<DD> error flag returned by routines on a failure (-1).
<DT> <CODE>OK</CODE>
<DD> error flag returned by routines when things go right.
</DL>

<H2><A NAME="using">Using the Library</A></H2>

Now we describe how to actually use the screen package.  In it, we assume all
updating, reading, etc. is applied to <CODE>stdscr</CODE>.  These instructions will
work on any window, providing you change the function names and parameters as
mentioned above. <P>

Here is a sample program to motivate the discussion:

<PRE>
#include &lt;curses.h&gt;
#include &lt;signal.h&gt;

static void finish(int sig);

int
main(int argc, char *argv[])
{
    int num = 0;

    /* initialize your non-curses data structures here */

    (void) signal(SIGINT, finish);      /* arrange interrupts to terminate */

    (void) initscr();      /* initialize the curses library */
    keypad(stdscr, TRUE);  /* enable keyboard mapping */
    (void) nonl();         /* tell curses not to do NL-&gt;CR/NL on output */
    (void) cbreak();       /* take input chars one at a time, no wait for \n */
    (void) echo();         /* echo input - in color */

    if (has_colors())
    {
        start_color();

        /*
         * Simple color assignment, often all we need.  Color pair 0 cannot
	 * be redefined.  This example uses the same value for the color
	 * pair as for the foreground color, though of course that is not
	 * necessary:
         */
        init_pair(1, COLOR_RED,     COLOR_BLACK);
        init_pair(2, COLOR_GREEN,   COLOR_BLACK);
        init_pair(3, COLOR_YELLOW,  COLOR_BLACK);
        init_pair(4, COLOR_BLUE,    COLOR_BLACK);
        init_pair(5, COLOR_CYAN,    COLOR_BLACK);
        init_pair(6, COLOR_MAGENTA, COLOR_BLACK);
        init_pair(7, COLOR_WHITE,   COLOR_BLACK);
    }

    for (;;)
    {
        int c = getch();     /* refresh, accept single keystroke of input */
	attrset(COLOR_PAIR(num % 8));
	num++;

        /* process the command keystroke */
    }

    finish(0);               /* we're done */
}

static void finish(int sig)
{
    endwin();

    /* do your non-curses wrapup here */

    exit(0);
}
</PRE>

<H3><A NAME="starting">Starting up</A></H3>

In order to use the screen package, the routines must know about terminal
characteristics, and the space for <CODE>curscr</CODE> and <CODE>stdscr</CODE> must be
allocated.  These function <CODE>initscr()</CODE> does both these things. Since it
must allocate space for the windows, it can overflow memory when attempting to
do so. On the rare occasions this happens, <CODE>initscr()</CODE> will terminate
the program with an error message.  <CODE>initscr()</CODE> must always be called
before any of the routines which affect windows are used.  If it is not, the
program will core dump as soon as either <CODE>curscr</CODE> or <CODE>stdscr</CODE> are
referenced.  However, it is usually best to wait to call it until after you are
sure you will need it, like after checking for startup errors.  Terminal status
changing routines like <CODE>nl()</CODE> and <CODE>cbreak()</CODE> should be called
after <CODE>initscr()</CODE>. <P>

Once the screen windows have been allocated, you can set them up for
your program.  If you want to, say, allow a screen to scroll, use
<CODE>scrollok()</CODE>.  If you want the cursor to be left in place after
the last change, use <CODE>leaveok()</CODE>.  If this isn't done,
<CODE>refresh()</CODE> will move the cursor to the window's current (y, x)
coordinates after updating it. <P>

You can create new windows of your own using the functions <CODE>newwin()</CODE>,
<CODE>derwin()</CODE>, and <CODE>subwin()</CODE>.  The routine <CODE>delwin()</CODE> will
allow you to get rid of old windows.  All the options described above can be
applied to any window.

<H3><A NAME="output">Output</A></H3>

Now that we have set things up, we will want to actually update the terminal.
The basic functions used to change what will go on a window are
<CODE>addch()</CODE> and <CODE>move()</CODE>.  <CODE>addch()</CODE> adds a character at the
current (y, x) coordinates.  <CODE>move()</CODE> changes the current (y, x)
coordinates to whatever you want them to be.  It returns <CODE>ERR</CODE> if you
try to move off the window.  As mentioned above, you can combine the two into
<CODE>mvaddch()</CODE> to do both things at once. <P>

The other output functions, such as <CODE>addstr()</CODE> and <CODE>printw()</CODE>,
all call <CODE>addch()</CODE> to add characters to the window. <P>

After you have put on the window what you want there, when you want the portion
of the terminal covered by the window to be made to look like it, you must call
<CODE>refresh()</CODE>.  In order to optimize finding changes, <CODE>refresh()</CODE>
assumes that any part of the window not changed since the last
<CODE>refresh()</CODE> of that window has not been changed on the terminal, i.e.,
that you have not refreshed a portion of the terminal with an overlapping
window.  If this is not the case, the routine <CODE>touchwin()</CODE> is provided
to make it look like the entire window has been changed, thus making
<CODE>refresh()</CODE> check the whole subsection of the terminal for changes. <P>

If you call <CODE>wrefresh()</CODE> with <CODE>curscr</CODE> as its argument, it will
make the screen look like <CODE>curscr</CODE> thinks it looks like.  This is useful
for implementing a command which would redraw the screen in case it get messed
up.

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

The complementary function to <CODE>addch()</CODE> is <CODE>getch()</CODE> which, if
echo is set, will call <CODE>addch()</CODE> to echo the character.  Since the
screen package needs to know what is on the terminal at all times, if
characters are to be echoed, the tty must be in raw or cbreak mode.  Since
initially the terminal has echoing enabled and is in ordinary ``cooked'' mode,
one or the other has to changed before calling <CODE>getch()</CODE>; otherwise,
the program's output will be unpredictable. <P>

When you need to accept line-oriented input in a window, the functions
<CODE>wgetstr()</CODE> and friends are available.  There is even a <CODE>wscanw()</CODE>
function that can do <CODE>scanf()</CODE>(3)-style multi-field parsing on window
input.  These pseudo-line-oriented functions turn on echoing while they
execute. <P>

The example code above uses the call <CODE>keypad(stdscr, TRUE)</CODE> to enable
support for function-key mapping.  With this feature, the <CODE>getch()</CODE> code
watches the input stream for character sequences that correspond to arrow and
function keys.  These sequences are returned as pseudo-character values.  The
<CODE>#define</CODE> values returned are listed in the <CODE>curses.h</CODE> The
mapping from sequences to <CODE>#define</CODE> values is determined by
<CODE>key_</CODE> capabilities in the terminal's terminfo entry.

<H3><A NAME="formschars">Using Forms Characters</A></H3>

The <CODE>addch()</CODE> function (and some others, including <CODE>box()</CODE> and
<CODE>border()</CODE>) can accept some pseudo-character arguments which are specially
defined by <CODE>ncurses</CODE>.  These are <CODE>#define</CODE> values set up in
the <CODE>curses.h</CODE> header; see there for a complete list (look for
the prefix <CODE>ACS_</CODE>). <P>

The most useful of the ACS defines are the forms-drawing characters.  You can
use these to draw boxes and simple graphs on the screen.  If the terminal
does not have such characters, <CODE>curses.h</CODE> will map them to a
recognizable (though ugly) set of ASCII defaults.