These functions provide an interface to mouse events from
ncurses(3x). Mouse events are represented by KEY_MOUSE
pseudo-key values in the wgetch input stream.
@@ -97,7 +98,6 @@
Here are the mouse event type masks which may be defined:
-
NameDescription
---------------------------------------------------------------------
BUTTON1_PRESSED mouse button 1 down
@@ -112,8 +112,8 @@
BUTTON2_DOUBLE_CLICKED mouse button 2 double clicked
BUTTON2_TRIPLE_CLICKED mouse button 2 triple clicked
---------------------------------------------------------------------
-
BUTTON3_PRESSED mouse button 3 down
+
BUTTON3_RELEASED mouse button 3 up
BUTTON3_CLICKED mouse button 3 clicked
BUTTON3_DOUBLE_CLICKED mouse button 3 double clicked
@@ -138,7 +138,7 @@
REPORT_MOUSE_POSITION report mouse movement
---------------------------------------------------------------------
- Once a class of mouse events have been made visible in a
+ Once a class of mouse events has been made visible in a
window, calling the wgetch function on that window may re-
turn KEY_MOUSE as an indicator that a mouse event has been
queued. To read the event data and pop the event off the
@@ -148,7 +148,9 @@
as y and x in the event structure coordinates will be
screen-relative character-cell coordinates. The returned
state mask will have exactly one bit set to indicate the
- event type.
+ 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.
The ungetmouse function behaves analogously to ungetch.
It pushes a KEY_MOUSE event onto the input queue, and as-
@@ -162,36 +164,42 @@
screen windows enclose the location of a mouse event.
The wmouse_trafo function transforms a given pair of coor-
- dinates from stdscr-relative coordinates to screen-rela-
- tive coordinates or vice versa. Please remember, that
- stdscr-relative coordinates are not always identical to
- screen-relative coordinates due to the mechanism to re-
- serve lines on top or bottom of the screen for other pur-
- poses (ripoff() call, see also slk_... functions). 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 screen-relative coordinates
- and returned through the pointers. If the conversion was
- successful, the function returns TRUE. If one of the pa-
- rameters was NULL or the location is not inside the win-
- dow, FALSE is returned. If to_screen is FALSE, the point-
- ers pY,pX must reference screen-relative coordinates.
- They are converted to stdscr-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. Please
- notice, that the referenced coordinates are only replaced
- by the converted coordinates if the transformation was
- successful.
+ dinates from stdscr-relative coordinates to coordinates
+ relative to the given window or vice versa. Please remem-
+ ber, that stdscr-relative coordinates are not always iden-
+ tical 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 calls, for ex-
+ ample). 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 window-relative co-
+ ordinates and returned through the pointers. If the con-
+ version was successful, the function returns TRUE. If one
+ of the parameters was NULL or the location is not inside
+ the window, FALSE is returned. If to_screen is FALSE, the
+ pointers pY,pX must reference window-relative coordi-
+ nates. They are converted to stdscr-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.
+ Please notice, that the referenced coordinates are only
+ replaced by the converted coordinates if the transforma-
+ tion was successful.
+
+ The mouse_trafo function performs the same translation as
+ wmouse_trafo, using stdscr for win.
The mouseinterval function sets the maximum time (in thou-
- sands of a second) that can elapse between press and re-
- lease events for them to be recognized as a click. Use
- mouseinterval(0) to disable click resolution. This func-
+ sands of a second) that can elapse between press and re-
+ lease events for them to be recognized as a click. Use
+ mouseinterval(0) to disable click resolution. This func-
tion returns the previous interval value. Use mouseinter-
- val(-1) to obtain the interval without altering it. The
+ val(-1) to obtain the interval without altering it. The
default is one sixth of a second.
+ The has_mouse function returns TRUE if the mouse driver
+ has been successfully initialized.
+
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 get-
@@ -199,13 +207,15 @@
getmouse and ungetmouse return the integer ERR upon fail-
ure or OK upon successful completion.
getmouse
returns an error. If no mouse driver was ini-
- tialized, or if the mask parameter is zero,
+ tialized, or if the mask parameter is zero, it
+ also returns an error if no more events remain
+ in the queue.
ungetmouse
returns an error if the FIFO is full.
@@ -221,7 +231,7 @@
These calls were designed for ncurses(3x), and are not
found in SVr4 curses, 4.4BSD curses, or any other previous
version of curses.
@@ -247,7 +257,7 @@
Under ncurses(3x), these calls are implemented using ei-
ther xterm's built-in mouse-tracking API or platform-spe-
cific drivers including
- Alessandro Rubini's gpm server.
+ Alessandro Rubini's gpm server
FreeBSD sysmouse
OS/2 EMX
If you are using an unsupported configuration, mouse
@@ -259,14 +269,21 @@
is initialized for mouse operation. The default, if XM is
not found, corresponds to private mode 1000 of xterm:
\E[?1000%?%p1%{1}%=%th%el%;
+
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 ALL_MOUSE_EVENTS class does not include RE-
+ PORT_MOUSE_POSITION. They are distinct. For example, in
+ xterm, wheel/scrolling mice send position reports as a se-
+ quence of presses of buttons 4 or 5 without matching but-
+ ton-releases.
+
Mouse events under xterm will not in fact be ignored dur-
ing cooked mode, if they have been enabled by mousemask.
Instead, the xterm mouse report sequence will appear in
@@ -275,8 +292,10 @@
Mouse events under xterm will not be detected correctly in
a window with its keypad bit off, since they are inter-
preted as a variety of function key. Your terminfo de-
- scription must have kmous set to "\E[M" (the beginning of
- the response from xterm for mouse clicks).
+ scription should have kmous set to "\E[M" (the beginning
+ of the response from xterm for mouse clicks). Other val-
+ ues for kmous are permitted, but under the same assump-
+ tion, i.e., it is the beginning of the response.
Because there are no standard terminal responses that
would serve to identify terminals which support the xterm
@@ -287,17 +306,24 @@