In making available the generalized terminal descriptions in ,
much information was made available to the programmer, but little
work was taken out of one’s hands. The purpose of this package
is to allow the C programmer to do the most common type of termi‐
nal dependent functions, those of movement optimization and opti‐
mal screen updating, without doing any of the dirty work, and
with nearly as much ease as is necessary to simply print or readthings. In this document, the following terminology is used:
An internal representation containing an image of what a section
of the terminal screen may look like at some point in time.
This subsection can either encompass the entire terminal
screen, or any smaller portion down to a single character
within that screen.
Sometimes called The package’s idea of what the terminal’s screen
currently looks like, what the user sees now. This is a
special
This is a subset of windows which are as large as the terminal
screen, they start at the upper left hand corner and encom‐
pass the lower right hand corner. One of these, is automat‐
ically provided for the programmer. In order to use the li‐
brary, it is necessary to have certain types and variables
defined. Therefore, the programmer must have a line: at the
top of the program source. Compilations should have the
following form: cc [ flags ] file ... −lcurses −ltermcap 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 is defined which
describes a window image to the routines, including its
starting position on the screen (the of the upper left hand
corner) and its size. One of these (called for is a screen
image of what the terminal currently looks like. Another
screen (called for is provided by default to make changes
on. 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 is more like an
array of characters on which to make changes. When one has
a window which describes what some part the terminal should
look like, the routine (or if the window is not is called.
makes the terminal, in the area covered by the window, look
like that window. Note, therefore, that changing something
on a window Actual updates to the terminal screen are made
only by calling or This allows the programmer to maintain
several different ideas of what a portion of the terminal
screen should look like. Also, changes can be made to win‐
dows in any order, without regard to motion efficiency.
Then, at will, the programmer can effectively say and the
package will execute the changes in an optimal way. As
hinted above, the routines can use several windows, but two
are always available: which is the image of what the termi‐
nal looks like at present, and which is the image of what
the programmer wants the terminal to look like next. The
user should not access directly. Changes should be made to
the appropriate screen, and then the routine (or should be
called. Many functions are set up to deal with as a default
screen. For example, to add a character to one calls with
the desired character. If a different window is to be used,
the routine (for is provided.
Actually, is really a macro with arguments, as are most of
the "functions" which act upon This convention of prepending
function names with a when they are to be applied to specif‐
ic windows is consistent. The only routines which do do
this are those to which a window must always be specified.
In order to move the current from one point to another, the
routines and 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 and the desired can then be added to the argu‐
ments to the function. For example, the calls move(yx); ad‐
dch(ch); can be replaced by mvaddch(yxch); and wmove(winyx);
waddch(winch); can be replaced by mvwaddch(winyxch); Note
that the window description pointer comes before the added .
If a window pointer is needed, it is always the first param‐
eter passed.