]> ncurses.scripts.mit.edu Git - ncurses.git/blobdiff - doc/html/ncurses-intro.html
ncurses 5.5
[ncurses.git] / doc / html / ncurses-intro.html
index 3500e7a6f84636edb04b3297d8d917d9ba8cb15c..1f09a7c2a265b5dc297f6e1947c17610935c1cfb 100644 (file)
@@ -1,11 +1,12 @@
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
 <!--
-  $Id: ncurses-intro.html,v 1.36 2002/07/06 15:50:36 juergen Exp $
+  $Id: ncurses-intro.html,v 1.40 2004/06/05 19:10:10 tom Exp $
 -->
 <HTML>
 <HEAD>
 <TITLE>Writing Programs with NCURSES</TITLE>
 <link rev="made" href="mailto:bugs-ncurses@gnu.org">
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </HEAD>
 <BODY>
 
@@ -221,16 +222,11 @@ maintainer of this package is
 &lt;esr@snark.thyrsus.com&gt;
 wrote many of the new features in versions after 1.8.1
 and wrote most of this introduction.
-<A HREF="http://www.familiepfeifer.de/Contact.aspx?Lang=en">J&uuml;rgen Pfeifer</A>
+J&uuml;rgen Pfeifer
 wrote all of the menu and forms code as well as the
 <A HREF="http://www.adahome.com">Ada95</A> binding.
 Ongoing work is being done by
-<A HREF="mailto:dickey@herndon4.his.com">Thomas Dickey</A>
-and
-<A HREF="http://www.familiepfeifer.de/Contact.aspx?Lang=en">J&uuml;rgen Pfeifer</A>.
-<A HREF="mailto:florian@gnu.org">Florian La Roche</A>
-acts as the maintainer for the Free Software Foundation, which holds the
-copyright on ncurses.
+<A HREF="mailto:dickey@invisible-island.net">Thomas Dickey</A> (maintainer).
 Contact the current maintainers at
 <A HREF="mailto:bug-ncurses@gnu.org">bug-ncurses@gnu.org</A>.
 <P>
@@ -613,6 +609,7 @@ Presently, mouse event reporting works in the following environments:
 <li>xterm and similar programs such as rxvt.
 <li>Linux console, when configured with <CODE>gpm</CODE>(1), Alessandro
 Rubini's mouse server.
+<li>FreeBSD sysmouse (console)
 <li>OS/2 EMX
 </ul>
 <P>
@@ -690,7 +687,7 @@ the first call to <CODE>refresh()</CODE> will clear the screen.  If an error
 occurs a message is written to standard error and the program
 exits. Otherwise it returns a pointer to stdscr.  A few functions may be
 called before initscr (<CODE>slk_init()</CODE>, <CODE>filter()</CODE>,
-<CODE>ripofflines()</CODE>, <CODE>use_env()</CODE>, and, if you are using multiple
+<CODE>ripoffline()</CODE>, <CODE>use_env()</CODE>, and, if you are using multiple
 terminals, <CODE>newterm()</CODE>.)
 <DT> <CODE>endwin()</CODE>
 <DD> Your program should always call <CODE>endwin()</CODE> before exiting or
@@ -732,7 +729,7 @@ the  terminal,  as  other  routines  merely  manipulate data
 structures.  <CODE>wrefresh()</CODE> copies the named window  to the physical
 terminal screen,  taking  into account  what is already
 there in  order to  do optimizations.  <CODE>refresh()</CODE> does a
-refresh of <CODE>stdscr()</CODE>.   Unless <CODE>leaveok()</CODE> has been
+refresh of <CODE>stdscr</CODE>.   Unless <CODE>leaveok()</CODE> has been
 enabled, the physical cursor of the terminal is left at  the
 location of the window's cursor.
 <DT> <CODE>doupdate()</CODE> and <CODE>wnoutrefresh(win)</CODE>
@@ -1020,7 +1017,7 @@ guarantee an entire-contents copy anywhere. <P>
 
 The really clean way to handle this is to use the panels library.  If,
 when you want a screen update, you do <CODE>update_panels()</CODE>, it will
-do all the necessary <CODE>wnoutrfresh()</CODE> calls for whatever panel
+do all the necessary <CODE>wnoutrefresh()</CODE> calls for whatever panel
 stacking order you have defined.  Then you can do one <CODE>doupdate()</CODE>
 and there will be a <EM>single</EM> burst of physical I/O that will do
 all your updates.
@@ -1222,10 +1219,10 @@ The general flow of control of a menu program looks like this:
 <LI>Initialize <CODE>curses</CODE>.
 <LI>Create the menu items, using <CODE>new_item()</CODE>.
 <LI>Create the menu using <CODE>new_menu()</CODE>.
-<LI>Post the menu using <CODE>menu_post()</CODE>.
+<LI>Post the menu using <CODE>post_menu()</CODE>.
 <LI>Refresh the screen.
 <LI>Process user requests via an input loop.
-<LI>Unpost the menu using <CODE>menu_unpost()</CODE>.
+<LI>Unpost the menu using <CODE>unpost_menu()</CODE>.
 <LI>Free the menu, using <CODE>free_menu()</CODE>.
 <LI>Free the items using <CODE>free_item()</CODE>.
 <LI>Terminate <CODE>curses</CODE>.
@@ -1308,8 +1305,8 @@ refreshed or erased at post/unpost time.  The inner window or
 By default, both windows are <CODE>stdscr</CODE>.  You can set them with the
 functions in <CODE>menu_win(3x)</CODE>. <P>
 
-When you call <CODE>menu_post()</CODE>, you write the menu to its
-subwindow.  When you call <CODE>menu_unpost()</CODE>, you erase the
+When you call <CODE>post_menu()</CODE>, you write the menu to its
+subwindow.  When you call <CODE>unpost_menu()</CODE>, you erase the
 subwindow, However, neither of these actually modifies the screen.  To
 do that, call <CODE>wrefresh()</CODE> or some equivalent.
 
@@ -1441,10 +1438,10 @@ The general flow of control of a form program looks like this:
 <LI>Initialize <CODE>curses</CODE>.
 <LI>Create the form fields, using <CODE>new_field()</CODE>.
 <LI>Create the form using <CODE>new_form()</CODE>.
-<LI>Post the form using <CODE>form_post()</CODE>.
+<LI>Post the form using <CODE>post_form()</CODE>.
 <LI>Refresh the screen.
 <LI>Process user requests via an input loop.
-<LI>Unpost the form using <CODE>form_unpost()</CODE>.
+<LI>Unpost the form using <CODE>unpost_form()</CODE>.
 <LI>Free the form, using <CODE>free_form()</CODE>.
 <LI>Free the fields using <CODE>free_field()</CODE>.
 <LI>Terminate <CODE>curses</CODE>.
@@ -1480,7 +1477,7 @@ the screen (the third and fourth arguments, which must be zero or
 greater). Note that these coordinates are relative to the form
 subwindow, which will coincide with <CODE>stdscr</CODE> by default but
 need not be <CODE>stdscr</CODE> if you've done an explicit
-<CODE>set_form_window()</CODE> call. <P>
+<CODE>set_form_win()</CODE> call. <P>
 
 The fifth argument allows you to specify a number of off-screen rows.  If
 this is zero, the entire field will always be displayed.  If it is
@@ -2519,13 +2516,13 @@ By default, all options are on.  Here are the available option bits:
 <DL>
 <DT> O_NL_OVERLOAD
 <DD> Enable overloading of <CODE>REQ_NEW_LINE</CODE> as described in <A
-NAME="fedit">Editing Requests</A>.  The value of this option is
+href="#fedit">Editing Requests</A>.  The value of this option is
 ignored on dynamic fields that have not reached their size limit;
 these have no last line, so the circumstances for triggering a
 <CODE>REQ_NEXT_FIELD</CODE> never arise.
 <DT> O_BS_OVERLOAD
 <DD> Enable overloading of <CODE>REQ_DEL_PREV</CODE> as described in
-<A NAME="fedit">Editing Requests</A>.
+<A href="#fedit">Editing Requests</A>.
 </DL>
 
 The option values are bit-masks and can be composed with logical-or in