X-Git-Url: http://ncurses.scripts.mit.edu/?p=ncurses.git;a=blobdiff_plain;f=doc%2Fhtml%2Fncurses-intro.html;h=a6cd40c74ddb9aa602d114e2028213c85bb8e386;hp=3500e7a6f84636edb04b3297d8d917d9ba8cb15c;hb=302a066a01e4de40f08b397e87ca0e97f20870a7;hpb=46722468f47c2b77b3987729b4bcf2321cccfd01 diff --git a/doc/html/ncurses-intro.html b/doc/html/ncurses-intro.html index 3500e7a6..a6cd40c7 100644 --- a/doc/html/ncurses-intro.html +++ b/doc/html/ncurses-intro.html @@ -1,11 +1,39 @@ - + Writing Programs with NCURSES + @@ -221,16 +249,11 @@ maintainer of this package is <esr@snark.thyrsus.com> wrote many of the new features in versions after 1.8.1 and wrote most of this introduction. -Jürgen Pfeifer +Jürgen Pfeifer wrote all of the menu and forms code as well as the Ada95 binding. Ongoing work is being done by -Thomas Dickey -and -Jürgen Pfeifer. -Florian La Roche -acts as the maintainer for the Free Software Foundation, which holds the -copyright on ncurses. +Thomas Dickey (maintainer). Contact the current maintainers at bug-ncurses@gnu.org.

@@ -408,6 +431,7 @@ mentioned above.

Here is a sample program to motivate the discussion:

+#include <stdlib.h>
 #include <curses.h>
 #include <signal.h>
 
@@ -613,6 +637,7 @@ Presently, mouse event reporting works in the following environments:
 
  • xterm and similar programs such as rxvt.
  • Linux console, when configured with gpm(1), Alessandro Rubini's mouse server. +
  • FreeBSD sysmouse (console)
  • OS/2 EMX

    @@ -690,7 +715,7 @@ the first call to refresh() 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 (slk_init(), filter(), -ripofflines(), use_env(), and, if you are using multiple +ripoffline(), use_env(), and, if you are using multiple terminals, newterm().)

    endwin()
    Your program should always call endwin() before exiting or @@ -732,7 +757,7 @@ the terminal, as other routines merely manipulate data structures. wrefresh() copies the named window to the physical terminal screen, taking into account what is already there in order to do optimizations. refresh() does a -refresh of stdscr(). Unless leaveok() has been +refresh of stdscr. Unless leaveok() has been enabled, the physical cursor of the terminal is left at the location of the window's cursor.
    doupdate() and wnoutrefresh(win) @@ -890,15 +915,14 @@ Here is some sample code for shellout:

    Using NCURSES under XTERM

    -A resize operation in X sends SIGWINCH to the application running under xterm. -The ncurses library provides an experimental signal -handler, but in general does not catch this signal, because it cannot -know how you want the screen re-painted. You will usually have to write the -SIGWINCH handler yourself. Ncurses can give you some help.

    +A resize operation in X sends SIGWINCH to the application running +under xterm. -The easiest way to code your SIGWINCH handler is to have it do an -endwin, followed by an refresh and a screen repaint you code -yourself. The refresh will pick up the new screen size from the +The easiest way to handle SIGWINCH +is to do an endwin, +followed by an refresh and a screen repaint you code +yourself. +The refresh will pick up the new screen size from the xterm's environment.

    That is the standard way, of course (it even works with some vendor's curses @@ -910,8 +934,17 @@ not resize subwindows which must be shrunk. are limited to the new screen dimensions, and pads stdscr with blanks if the screen is larger.

    -Finally, ncurses can be configured to provide its own SIGWINCH handler, -based on resizeterm. +The ncurses library provides a SIGWINCH signal handler, +which pushes a KEY_RESIZE via the wgetch() calls. +When ncurses returns that code, +it calls resizeterm +to update the size of the standard screen's window, repainting that +(filling with blanks or truncating as needed). +It also resizes other windows, +but its effect may be less satisfactory because it cannot +know how you want the screen re-painted. +You will usually have to write special-purpose code to handle +KEY_RESIZE yourself.

    Handling Multiple Terminal Screens

    @@ -982,7 +1015,7 @@ on and refresh them, the changes made to the overlapping region under historic To understand why this is a problem, remember that screen updates are calculated between two representations of the entire display. The -documentation says that when you refresh a window, it is first copied to to the +documentation says that when you refresh a window, it is first copied to the virtual screen, and then changes are calculated to update the physical screen (and applied to the terminal). But "copied to" is not very specific, and subtle differences in how copying works can produce different behaviors in the @@ -1020,7 +1053,7 @@ guarantee an entire-contents copy anywhere.

    The really clean way to handle this is to use the panels library. If, when you want a screen update, you do update_panels(), it will -do all the necessary wnoutrfresh() calls for whatever panel +do all the necessary wnoutrefresh() calls for whatever panel stacking order you have defined. Then you can do one doupdate() and there will be a single burst of physical I/O that will do all your updates. @@ -1222,10 +1255,10 @@ The general flow of control of a menu program looks like this:

  • Initialize curses.
  • Create the menu items, using new_item().
  • Create the menu using new_menu(). -
  • Post the menu using menu_post(). +
  • Post the menu using post_menu().
  • Refresh the screen.
  • Process user requests via an input loop. -
  • Unpost the menu using menu_unpost(). +
  • Unpost the menu using unpost_menu().
  • Free the menu, using free_menu().
  • Free the items using free_item().
  • Terminate curses. @@ -1308,8 +1341,8 @@ refreshed or erased at post/unpost time. The inner window or By default, both windows are stdscr. You can set them with the functions in menu_win(3x).

    -When you call menu_post(), you write the menu to its -subwindow. When you call menu_unpost(), you erase the +When you call post_menu(), you write the menu to its +subwindow. When you call unpost_menu(), you erase the subwindow, However, neither of these actually modifies the screen. To do that, call wrefresh() or some equivalent. @@ -1441,10 +1474,10 @@ The general flow of control of a form program looks like this:

  • Initialize curses.
  • Create the form fields, using new_field().
  • Create the form using new_form(). -
  • Post the form using form_post(). +
  • Post the form using post_form().
  • Refresh the screen.
  • Process user requests via an input loop. -
  • Unpost the form using form_unpost(). +
  • Unpost the form using unpost_form().
  • Free the form, using free_form().
  • Free the fields using free_field().
  • Terminate curses. @@ -1480,7 +1513,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 stdscr by default but need not be stdscr if you've done an explicit -set_form_window() call.

    +set_form_win() call.

    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 @@ -2160,7 +2193,7 @@ These requests treat the list as cyclic; that is, REQ_NEXT_PAGE from the last page goes to the first, and REQ_PREV_PAGE from the first page goes to the last. -

    Inter-Field Navigation Requests

    +

    Inter-Field Navigation Requests

    These requests handle navigation between fields on the same page. @@ -2214,7 +2247,7 @@ of B and C to the right of B. A REQ_MOVE_RIGHT from A will go to B only if A, B, and C all share the same first line; otherwise it will skip over B to C. -

    Intra-Field Navigation Requests

    +

    Intra-Field Navigation Requests

    These requests drive movement of the edit cursor within the currently selected field. @@ -2519,13 +2552,13 @@ By default, all options are on. Here are the available option bits:
    O_NL_OVERLOAD
    Enable overloading of REQ_NEW_LINE as described in Editing Requests. The value of this option is +href="#fedit">Editing Requests. 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 REQ_NEXT_FIELD never arise.
    O_BS_OVERLOAD
    Enable overloading of REQ_DEL_PREV as described in -Editing Requests. +Editing Requests.
    The option values are bit-masks and can be composed with logical-or in