release.sh: restore -jJAILDIR option
[minix.git] / lib / libcurses / PSD.doc / intro.1
blob14d1e39b06dfa3307a2b34a8faa503d7e2a65d7f
1 .\"     $NetBSD: intro.1,v 1.7 2003/08/07 16:44:27 agc Exp $
2 .\"
3 .\" Copyright (c) 1980, 1993
4 .\"     The Regents of the University of California.  All rights reserved.
5 .\"
6 .\" Redistribution and use in source and binary forms, with or without
7 .\" modification, are permitted provided that the following conditions
8 .\" are met:
9 .\" 1. Redistributions of source code must retain the above copyright
10 .\"    notice, this list of conditions and the following disclaimer.
11 .\" 2. Redistributions in binary form must reproduce the above copyright
12 .\"    notice, this list of conditions and the following disclaimer in the
13 .\"    documentation and/or other materials provided with the distribution.
14 .\" 3. Neither the name of the University nor the names of its contributors
15 .\"    may be used to endorse or promote products derived from this software
16 .\"    without specific prior written permission.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
19 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
22 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
24 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
25 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
26 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
27 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" SUCH DAMAGE.
29 .\"
30 .\"     @(#)intro.1     8.1 (Berkeley) 6/4/93
31 .\"
32 .bp
33 .sh 1 Overview
34 .pp
35 In making available the generalized terminal descriptions in \*(tc,
36 much information was made available to the programmer,
37 but little work was taken out of one's hands.
38 The purpose of this package is to allow the C programmer
39 to do the most common type of terminal dependent functions,
40 those of movement optimization and optimal screen updating,
41 without doing any of the dirty work,
42 and with nearly as much ease as is necessary to simply print
43 or read things.
44 .sh 2 "Terminology"
45 .pp
46 In this document, the following terminology is used:
47 .de Ip
48 .sp
49 .in 5n
50 .ti 0n
51 .b "\\$1" :
53 .Ip window
54 An internal representation
55 containing an image of what a section of the terminal screen may look like
56 at some point in time.
57 This subsection can either encompass the entire terminal screen,
58 or any smaller portion down to a single character within that screen.
59 .Ip terminal
60 Sometimes called
61 .b terminal
62 .b screen .
63 The package's idea of what the terminal's screen currently looks like,
64 .i i.e. ,
65 what the user sees now.
66 This is a special
67 .i screen :
68 .Ip screen
69 This is a subset of windows which are as large as the terminal screen,
70 .i i.e. ,
71 they start at the upper left hand corner
72 and encompass the lower right hand corner.
73 One of these,
74 .Vn stdscr ,
75 is automatically provided for the programmer.
76 .rm Ip
77 .sh 2 "Compiling Applications"
78 .pp
79 In order to use the library,
80 it is necessary to have certain types and variables defined.
81 Therefore, the programmer must have a line:
82 .(l
83 .b "#include <curses.h>"
84 .)l
85 at the top of the program source.
86 Compilations should have the following form:
87 .(l
88 .ie t \fBcc\fR [ \fIflags\fR ] file ... \fB\-lcurses \-ltermcap\fR
89 .el \fIcc\fR [ flags ] file ... \fI\-lcurses \-ltermcap\fR
90 .)l
91 .sh 2 "Screen Updating"
92 .pp
93 In order to update the screen optimally,
94 it is necessary for the routines to know what the screen currently looks like
95 and what the programmer wants it to look like next.
96 For this purpose,
97 a data type
98 (structure)
99 named
100 .Vn WINDOW
101 is defined
102 which describes a window image to the routines,
103 including its starting position on the screen
104 (the \*y of the upper left hand corner)
105 and its size.
106 One of these
107 (called
108 .Vn curscr
110 .i "current screen" )
111 is a screen image of what the terminal currently looks like.
112 Another screen
113 (called
114 .Vn stdscr ,
116 .i "standard screen" )
117 is provided
118 by default
119 to make changes on.
121 A window is a purely internal representation.
122 It is used to build and store
123 a potential image of a portion of the terminal.
124 It doesn't bear any necessary relation
125 to what is really on the terminal screen.
126 It is more like an array of characters on which to make changes.
128 When one has a window which describes
129 what some part the terminal should look like,
130 the routine
131 .Fn refresh
133 .Fn wrefresh
134 if the window is not
135 .Vn stdscr )
136 is called.
137 .Fn refresh
138 makes the terminal,
139 in the area covered by the window,
140 look like that window.
141 Note, therefore, that changing something on a window
142 .i does
143 .bi not
144 .i "change the terminal" .
145 Actual updates to the terminal screen
146 are made only by calling
147 .Fn refresh
149 .Fn wrefresh .
150 This allows the programmer to maintain several different ideas
151 of what a portion of the terminal screen should look like.
152 Also, changes can be made to windows in any order,
153 without regard to motion efficiency.
154 Then, at will,
155 the programmer can effectively say
156 .q "make it look like this" ,
157 and the package will execute the changes in an optimal way.
158 .sh 2 "Naming Conventions"
160 As hinted above,
161 the routines can use several windows,
162 but two are always available:
163 .Vn curscr ,
164 which is the image of what the terminal looks like at present,
166 .Vn stdscr ,
167 which is the image of what the programmer wants the terminal to look like next.
168 The user should not access
169 .Vn curscr
170 directly.
171 Changes should be made to
172 the appropriate screen,
173 and then the routine
174 .Fn refresh
176 .Fn wrefresh )
177 should be called.
179 Many functions are set up to deal with
180 .Vn stdscr
181 as a default screen.
182 For example, to add a character to
183 .Vn stdscr ,
184 one calls
185 .Fn addch
186 with the desired character.
187 If a different window is to be used,
188 the routine
189 .Fn waddch
190 (for
191 .b w indow-specific
192 .Fn addch )
193 is provided\**.
196 Actually,
197 .Fn addch
198 is really a
199 .q #define
200 macro with arguments,
201 as are most of the "functions" which act upon
202 .Vn stdscr .
204 This convention of prepending function names with a
205 .Bq w
206 when they are to be applied to specific windows
207 is consistent.
208 The only routines which do
209 .i not
210 do this are those
211 to which a window must always be specified.
213 In order to move the current \*y from one point to another,
214 the routines
215 .Fn move
217 .Fn wmove
218 are provided.
219 However,
220 it is often desirable to first move and then perform some I/O operation.
221 In order to avoid clumsiness,
222 most I/O routines can be preceded by the prefix
223 .Bq mv
224 and the desired \*y can then be added to the arguments to the function.
225 For example,
226 the calls
228 move(y\*,x);
229 addch(ch);
231 can be replaced by
233 mvaddch(y\*,x\*,ch);
237 wmove(win\*,y\*,x);
238 waddch(win\*,ch);
240 can be replaced by
242 mvwaddch(win\*,y\*,x\*,ch);
244 Note that the window description pointer
245 .Vn win ) (
246 comes before the added \*y.
247 If a window pointer is needed, it is always the first parameter passed.