+ The has_mouse function returns TRUE if the mouse driver has been
+ successfully initialized, and FALSE otherwise.
+
+ Mouse events are ignored when input is in cooked mode, and cause an
+ error beep when cooked mode is being simulated in a window by a
+ function such as getstr that expects a linefeed for input-loop
+ termination.
+
+
- To make mouse events visible, use the mousemask function. This will
- set the mouse events to be reported. By default, no mouse events are
- reported. The function will return a mask to indicate which of the
- specified mouse events can be reported; on complete failure it returns
- 0. If oldmask is non-NULL, this function fills the indicated location
- with the previous value of the given window's mouse event mask.
-
- As a side effect, setting a zero mousemask may turn off the mouse
+ To make mouse events visible, use the mousemask function. This sets
+ the mouse events to be reported. By default, no mouse events are
+ reported.
+
+ o The function returns an updated copy of newmask to indicate which
+ of the specified mouse events can be reported.
+
+ If the screen has not been initialized, or if the terminal does not
+ support mouse-events, this function returns 0.
+
+ o If oldmask is non-NULL, this function fills the indicated location
+ with the previous value of the current screen's mouse event mask.
+
+ As a side effect, setting a zero mouse mask may turn off the mouse
pointer; setting a nonzero mask may turn it on. Whether this happens
is device-dependent.
-
@@ -143,11 +164,11 @@
event off the queue, call getmouse. This function will return OK if a
mouse event is actually visible in the given window, ERR otherwise.
When getmouse returns OK, the data deposited as y and x in the event
- structure coordinates will be screen-relative character-cell coordi-
- nates. The returned state mask will have exactly one bit set to indi-
- cate the event type. The corresponding data in the queue is marked in-
- valid. A subsequent call to getmouse will retrieve the next older item
- from the queue.
+ structure coordinates will be screen-relative character-cell
+ coordinates. The returned state mask will have exactly one bit set to
+ indicate the event type. The corresponding data in the queue is marked
+ invalid. A subsequent call to getmouse will retrieve the next older
+ item from the queue.
@@ -162,73 +183,83 @@
TRUE if it is and FALSE otherwise. It is useful for determining what
subset of the screen windows enclose the location of a mouse event.
+ If the parameter is a pad, wenclose uses the most recent screen
+ coordinates used for this pad in prefresh(3x) or pnoutrefresh(3x).
+
- The wmouse_trafo function transforms a given pair of coordinates from
- stdscr-relative coordinates to coordinates relative to the given window
- or vice versa. The resulting stdscr-relative coordinates are not al-
- ways identical to window-relative coordinates due to the mechanism to
- reserve lines on top or bottom of the screen for other purposes (see
- the ripoffline and slk_init(3x) calls, for example).
-
- o If the parameter to_screen is TRUE, the pointers pY,pX must refer-
- ence the coordinates of a location inside the window win. They are
- converted to window-relative coordinates and returned through the
- pointers. If the conversion was successful, the function returns
- TRUE.
-
- o If one of the parameters was NULL or the location is not inside the
+ The wmouse_trafo function transforms a given pair of coordinates from
+ stdscr-relative coordinates to coordinates relative to the given window
+ or vice versa. The resulting stdscr-relative coordinates are not
+ always identical to screen coordinates due to the mechanism to reserve
+ lines on top or bottom of the screen for other purposes (see the
+ ripoffline(3x) and slk_init(3x) calls, for example).
+
+ o If the parameter to_screen is TRUE, the pointers pY,pX must
+ reference the coordinates of a location inside the window win.
+ They are converted to stdscr-relative coordinates and returned
+ through the pointers. If the conversion was successful, the
+ function returns TRUE.
+
+ If one of the parameters was NULL or the location is not inside the
window, FALSE is returned.
- o If to_screen is FALSE, the pointers pY,pX must reference window-
- relative coordinates. They are converted to stdscr-relative coor-
- dinates if the window win encloses this point. In this case the
- function returns TRUE.
+ o If to_screen is FALSE, the pointers pY,pX must reference
+ stdscr-relative coordinates. They are converted to window-relative
+ coordinates if the window win encloses this point. In this case
+ the function returns TRUE.
+
+ If one of the parameters is NULL or the point is not inside the
+ window, FALSE is returned.
- o If one of the parameters is NULL or the point is not inside the
- window, FALSE is returned. The referenced coordinates are only re-
- placed by the converted coordinates if the transformation was suc-
- cessful.
+ The referenced coordinates are only replaced by the converted
+ coordinates if the transformation was successful.
The mouseinterval function sets the maximum time (in thousands of a
second) that can elapse between press and release events for them to be
- recognized as a click. Use mouseinterval(0) to disable click resolu-
- tion. This function returns the previous interval value. Use mousein-
- terval(-1) to obtain the interval without altering it. The default is
- one sixth of a second.
+ resolved as a click. An application might interpret button press and
+ release events separated by more than the mouse interval as a "long
+ press", or, with motion, as a "drag".
+ Calling mouseinterval(0) disables click resolution. When ncurses
+ detects a mouse event, it awaits further input activity up to this
+ interval, and then checks for a subsequent mouse event which can be
+ combined with the first event. If the timeout expires without input
+ activity (which would happen with a zero interval), then no click
+ resolution will occur.
-
- The has_mouse function returns TRUE if the mouse driver has been suc-
- cessfully initialized.
+ This function returns the previous interval value. Use
+ mouseinterval(-1) to obtain the interval without altering it.
- Note that mouse events will be ignored when input is in cooked mode,
- and will cause an error beep when cooked mode is being simulated in a
- window by a function such as getstr that expects a linefeed for input-
- loop termination.
+ The mouse interval is set to one sixth of a second when the
+ corresponding screen is initialized, e.g., in initscr(3x) or
+ setupterm(3x).
- getmouse and ungetmouse return the integer ERR upon failure or OK upon
- successful completion:
+ has_mouse, wenclose, mouse_trafo, and wmouse_trafo return TRUE or FALSE
+ as noted above.
+
+ getmouse and ungetmouse return ERR upon failure and OK upon success.
+
+ getmouse fails if:
+
+ o no mouse driver was initialized,
- getmouse
- returns an error.
+ o the mask of reportable events is zero,
- o If no mouse driver was initialized, or if the mask parameter is
- zero,
+ o a mouse event was detected that does not match the mask,
- o It also returns an error if no more events remain in the queue.
+ o or if no more events remain in the queue.
- ungetmouse
- returns an error if the FIFO is full.
+ ungetmouse returns an error if the event queue is full.
mousemask returns the mask of reportable events.
@@ -236,129 +267,134 @@
was not initialized. In that case, it returns the maximum interval
value (166).
- wenclose and wmouse_trafo are boolean functions returning TRUE or FALSE
- depending on their test result.
+
- These calls were designed for ncurses(3x), and are not found in SVr4
- curses, 4.4BSD curses, or any other previous version of curses.
+ Under ncurses, these calls are implemented using either xterm's built-
+ in mouse-tracking API or platform-specific drivers including
- SVr4 curses had support for the mouse in a variant of xterm. It is
- mentioned in a few places, but with no supporting documentation:
+ o Alessandro Rubini's gpm server
- o the "libcurses" manual page lists functions for this feature which
- are prototyped in curses.h:
+ o FreeBSD sysmouse
- extern int mouse_set(long int);
- extern int mouse_on(long int);
- extern int mouse_off(long int);
- extern int request_mouse_pos(void);
- extern int map_button(unsigned long);
- extern void wmouse_position(WINDOW *, int *, int *);
- extern unsigned long getmouse(void), getbmap(void);
+ o OS/2 EMX
- o the "terminfo" manual page lists capabilities for the feature
+ If you are using an unsupported configuration, mouse events will not be
+ visible to ncurses (and the mousemask function will always return 0).
- buttons btns BT Number of buttons on the mouse
- get_mouse getm Gm Curses should get button events
- key_mouse kmous Km 0631, Mouse event has occurred
- mouse_info minfo Mi Mouse status information
- req_mouse_pos reqmp RQ Request mouse position report
+ If the terminfo entry contains a XM string, this is used in the xterm
+ mouse driver to control the way the terminal is initialized for mouse
+ operation. The default, if XM is not found, corresponds to private
+ mode 1000 of xterm:
- o the interface made assumptions (as does ncurses) about the escape
- sequences sent to and received from the terminal.
+ \E[?1000%?%p1%{1}%=%th%el%;
- For instance the SVr4 curses library used the get_mouse capability
- to tell the terminal which mouse button events it should send,
- passing the mouse-button bit-mask to the terminal. Also, it could
- ask the terminal where the mouse was using the req_mouse_pos capa-
- bility.
+ The mouse driver also recognizes a newer xterm private mode 1006, e.g.,
- Those features required a terminal which had been modified to work
- with curses. They were not part of the X Consortium's xterm.
+ \E[?1006;1000%?%p1%{1}%=%th%el%;
- When developing the xterm mouse support for ncurses in September 1995,
- Eric Raymond was uninterested in using the same interface due to its
- lack of documentation. Later, in 1998, Mark Hesseling provided support
- in PDCurses 2.3 using the SVr4 interface. PDCurses, however, does not
- use video terminals, making it unnecessary to be concerned about com-
- patibility with the escape sequences.
+ The z member in the event structure is not presently used. It is
+ intended for use with touch screens (which may be pressure-sensitive)
+ or with 3D-mice/trackballs/power gloves.
- The feature macro NCURSES_MOUSE_VERSION is provided so the preprocessor
- can be used to test whether these features are present. If the inter-
- face is changed, the value of NCURSES_MOUSE_VERSION will be increment-
- ed. These values for NCURSES_MOUSE_VERSION may be specified when con-
- figuring ncurses:
+ The ALL_MOUSE_EVENTS class does not include REPORT_MOUSE_POSITION.
+ They are distinct. For example, in xterm, wheel/scrolling mice send
+ position reports as a sequence of presses of buttons 4 or 5 without
+ matching button-releases.
- 1 has definitions for reserved events. The mask uses 28 bits.
- 2 adds definitions for button 5, removes the definitions for re-
- served events. The mask uses 29 bits.
+
+ These functions were designed for ncurses(3x), and are not found in
+ SVr4 curses, 4.4BSD curses, or any other previous curses
+ implementation. (SVr4 curses did have a getmouse function, which took
+ no argument and returned a different type.)
- The order of the MEVENT structure members is not guaranteed. Addition-
- al fields may be added to the structure in the future.
- Under ncurses(3x), these calls are implemented using either xterm's
- built-in mouse-tracking API or platform-specific drivers including
+
+ Applications employing the ncurses mouse extension should condition its
+ use on the visibility of the NCURSES_MOUSE_VERSION preprocessor macro.
+ When the interface changes, the macro's value increments. Multiple
+ versions are available when ncurses is configured; see section
+ "ALTERNATE CONFIGURATIONS" of ncurses(3x). The following values may be
+ specified.
- o Alessandro Rubini's gpm server
+ 1 has definitions for reserved events. The mask uses 28 bits.
- o FreeBSD sysmouse
+ 2 adds definitions for button 5, removes the definitions for
+ reserved events. The mask uses 29 bits.
- o OS/2 EMX
+ SVr4 curses had support for the mouse in a variant of xterm(1). It is
+ mentioned in a few places, with little supporting documentation.
- If you are using an unsupported configuration, mouse events will not be
- visible to ncurses(3x) (and the mousemask function will always return
- 0).
+ o Its "libcurses" manual page lists functions for this feature
+ prototyped in curses.h.
- If the terminfo entry contains a XM string, this is used in the xterm
- mouse driver to control the way the terminal is initialized for mouse
- operation. The default, if XM is not found, corresponds to private
- mode 1000 of xterm:
+ extern int mouse_set(long int);
+ extern int mouse_on(long int);
+ extern int mouse_off(long int);
+ extern int request_mouse_pos(void);
+ extern int map_button(unsigned long);
+ extern void wmouse_position(WINDOW *, int *, int *);
+ extern unsigned long getmouse(void), getbmap(void);
- \E[?1000%?%p1%{1}%=%th%el%;
+ o Its "terminfo" manual page lists capabilities for the feature.
- The mouse driver also recognizes a newer xterm private mode 1006, e.g.,
+ buttonsbtnsBT Number of buttons on the mouse
+ get_mousegetmGm Curses should get button events
+ key_mousekmousKm 0631, Mouse event has occurred
+ mouse_infominfoMi Mouse status information
+ req_mouse_posreqmpRQ Request mouse position report
- \E[?1006;1000%?%p1%{1}%=%th%el%;
+ o The interface made assumptions (as does ncurses) about the escape
+ sequences sent to and received from the terminal.
- The z member in the event structure is not presently used. It is in-
- tended for use with touch screens (which may be pressure-sensitive) or
- with 3D-mice/trackballs/power gloves.
+ For instance, the SVr4 curses library used the get_mouse capability
+ to tell the terminal which mouse button events it should send,
+ passing the mouse-button bit mask to the terminal. Also, it could
+ ask the terminal where the mouse was using the req_mouse_pos
+ capability.
- The ALL_MOUSE_EVENTS class does not include REPORT_MOUSE_POSITION.
- They are distinct. For example, in xterm, wheel/scrolling mice send
- position reports as a sequence of presses of buttons 4 or 5 without
- matching button-releases.
+ Those features required a terminal program that had been modified
+ to work with SVr4 curses. They were not part of the X Consortium's
+ xterm.
+
+ When developing the xterm mouse support for ncurses in September 1995,
+ Eric Raymond was uninterested in using the same interface due to its
+ lack of documentation. Later, in 1998, Mark Hesseling provided support
+ in PDCurses 2.3 using the SVr4 interface. PDCurses, however, does not
+ use video terminals, making it unnecessary to be concerned about
+ compatibility with the escape sequences.
- Mouse events under xterm will not in fact be ignored during cooked
- mode, if they have been enabled by mousemask. Instead, the xterm mouse
- report sequence will appear in the string read.
+ Mouse events from xterm are not ignored in cooked mode if they have
+ been enabled by mousemask. Instead, the xterm mouse report sequence
+ appears in the string read.
- Mouse events under xterm will not be detected correctly in a window
- with its keypad bit off, since they are interpreted as a variety of
- function key. Your terminfo description should have kmous set to
- "\E[M" (the beginning of the response from xterm for mouse clicks).
- Other values for kmous are permitted, but under the same assumption,
- i.e., it is the beginning of the response.
+ Mouse event reports from xterm are not detected correctly in a window
+ with keypad application mode disabled, since they are interpreted as a
+ variety of function key. Set the terminal's terminfo capability kmous
+ to "\E[M" (the beginning of the response from xterm for mouse clicks).
+ Other values of kmous are permitted under the same assumption, that is,
+ the report begins with that sequence.
- Because there are no standard terminal responses that would serve to
- identify terminals which support the xterm mouse protocol, ncurses as-
- sumes that if your $TERM environment variable contains "xterm", or
- kmous is defined in the terminal description, then the terminal may
- send mouse events. The kmous capability is checked first, allowing the
- use of newer xterm mouse protocols.
+ Because there are no standard response sequences that serve to identify
+ terminals supporting the xterm mouse protocol, ncurses assumes that if
+ kmous is defined in the terminal description, or if the terminal type's
+ primary name or aliases contain the string "xterm", then the terminal
+ may send mouse events. The kmous capability is checked first, allowing
+ use of newer xterm mouse protocols, such as its private mode 1006.