* sale, use or other dealings in this Software without prior written *
* authorization. *
****************************************************************************
- * @Id: curs_mouse.3x,v 1.81 2023/10/21 10:29:45 tom Exp @
+ * @Id: curs_mouse.3x,v 1.82 2023/12/16 21:08:16 tom Exp @
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="generator" content="Manpage converted by man2html - see https://invisible-island.net/scripts/readme.html#others_scripts">
-<TITLE>curs_mouse 3x 2023-10-21 ncurses 6.4 Library calls</TITLE>
+<TITLE>curs_mouse 3x 2023-12-16 ncurses 6.4 Library calls</TITLE>
<link rel="author" href="mailto:bug-ncurses@gnu.org">
</HEAD>
<BODY>
-<H1 class="no-header">curs_mouse 3x 2023-10-21 ncurses 6.4 Library calls</H1>
+<H1 class="no-header">curs_mouse 3x 2023-12-16 ncurses 6.4 Library calls</H1>
<PRE>
<STRONG><A HREF="curs_mouse.3x.html">curs_mouse(3x)</A></STRONG> Library calls <STRONG><A HREF="curs_mouse.3x.html">curs_mouse(3x)</A></STRONG>
</PRE><H3><a name="h3-wmouse_trafo">wmouse_trafo</a></H3><PRE>
The <STRONG>wmouse_trafo</STRONG> 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
+ <STRONG>stdscr</STRONG>-relative coordinates to coordinates relative to the given window
+ or vice versa. The resulting <STRONG>stdscr</STRONG>-relative coordinates are not
always identical to window-relative coordinates due to the mechanism to
reserve lines on top or bottom of the screen for other purposes (see
the <STRONG>ripoffline</STRONG> and <STRONG><A HREF="curs_slk.3x.html">slk_init(3x)</A></STRONG> calls, for example).
window, <STRONG>FALSE</STRONG> is returned.
<STRONG>o</STRONG> If <EM>to</EM><STRONG>_</STRONG><EM>screen</EM> is <STRONG>FALSE</STRONG>, the pointers <EM>pY,</EM> <EM>pX</EM> must reference window-
- relative coordinates. They are converted to stdscr-relative
+ relative coordinates. They are converted to <STRONG>stdscr</STRONG>-relative
coordinates if the window <EM>win</EM> encloses this point. In this case
the function returns <STRONG>TRUE</STRONG>.
</PRE><H3><a name="h3-mouse_trafo">mouse_trafo</a></H3><PRE>
The <STRONG>mouse_trafo</STRONG> function performs the same translation as <STRONG>wmouse_trafo</STRONG>,
- using stdscr for <EM>win</EM>.
+ using <STRONG>stdscr</STRONG> for <EM>win</EM>.
</PRE><H3><a name="h3-mouseinterval">mouseinterval</a></H3><PRE>
</PRE><H3><a name="h3-has_mouse">has_mouse</a></H3><PRE>
The <STRONG>has_mouse</STRONG> function returns <STRONG>TRUE</STRONG> if the mouse driver has been
- successfully initialized.
+ successfully initialized, and <STRONG>FALSE</STRONG> otherwise.
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
</PRE><H2><a name="h2-RETURN-VALUE">RETURN VALUE</a></H2><PRE>
- <STRONG>getmouse</STRONG> and <STRONG>ungetmouse</STRONG> return the integer <STRONG>ERR</STRONG> upon failure or <STRONG>OK</STRONG> upon
- successful completion:
+ <STRONG>has_mouse</STRONG>, <STRONG>wenclose</STRONG>, <STRONG>mouse_trafo</STRONG>, and <STRONG>wmouse_trafo</STRONG> return <STRONG>TRUE</STRONG> or <STRONG>FALSE</STRONG>
+ as noted above.
- <STRONG>getmouse</STRONG>
- returns an error.
+ <STRONG>getmouse</STRONG> and <STRONG>ungetmouse</STRONG> return <STRONG>ERR</STRONG> upon failure and <STRONG>OK</STRONG> upon success.
- <STRONG>o</STRONG> If no mouse driver was initialized, or if the mask parameter is
- zero,
+ <STRONG>getmouse</STRONG> fails if:
- <STRONG>o</STRONG> It returns an error if a mouse event was detected which did not
- match the current <EM>mousemask</EM>.
+ <STRONG>o</STRONG> no mouse driver was initialized,
- <STRONG>o</STRONG> It also returns an error if no more events remain in the queue.
+ <STRONG>o</STRONG> the mask of reportable events is zero,
- <STRONG>ungetmouse</STRONG>
- returns an error if the FIFO is full.
+ <STRONG>o</STRONG> a mouse event was detected that does not match the mask,
+
+ <STRONG>o</STRONG> or if no more events remain in the queue.
+
+ <STRONG>ungetmouse</STRONG> returns an error if the event queue is full.
<STRONG>mousemask</STRONG> returns the mask of reportable events.
was not initialized. In that case, it returns the maximum interval
value (166).
- <STRONG>wenclose</STRONG> and <STRONG>wmouse_trafo</STRONG> are boolean functions returning <STRONG>TRUE</STRONG> or <STRONG>FALSE</STRONG>
- depending on their test result.
+
+</PRE><H2><a name="h2-NOTES">NOTES</a></H2><PRE>
+ The feature macro <STRONG>NCURSES_MOUSE_VERSION</STRONG> is provided so the preprocessor
+ can be used to test whether these features are present. If the
+ interface is changed, the value of <STRONG>NCURSES_MOUSE_VERSION</STRONG> will be
+ incremented. These values for <STRONG>NCURSES_MOUSE_VERSION</STRONG> may be specified
+ when configuring <EM>ncurses</EM>:
+
+ 1 has definitions for reserved events. The mask uses 28 bits.
+
+ 2 adds definitions for button 5, removes the definitions for
+ reserved events. The mask uses 29 bits.
+
+ The order of the <STRONG>MEVENT</STRONG> structure members is not guaranteed.
+ Additional fields may be added to the structure in the future.
+
+ Under <EM>ncurses</EM>, these calls are implemented using either xterm's built-
+ in mouse-tracking API or platform-specific drivers including
+
+ <STRONG>o</STRONG> Alessandro Rubini's gpm server
+
+ <STRONG>o</STRONG> FreeBSD sysmouse
+
+ <STRONG>o</STRONG> OS/2 EMX
+
+ If you are using an unsupported configuration, mouse events will not be
+ visible to <EM>ncurses</EM> (and the <STRONG>mousemask</STRONG> function will always return <STRONG>0</STRONG>).
+
+ If the terminfo entry contains a <STRONG>XM</STRONG> string, this is used in the xterm
+ mouse driver to control the way the terminal is initialized for mouse
+ operation. The default, if <STRONG>XM</STRONG> is not found, corresponds to private
+ mode 1000 of xterm:
+
+ \E[?1000%?%p1%{1}%=%th%el%;
+
+ The mouse driver also recognizes a newer xterm private mode 1006, e.g.,
+
+ \E[?1006;1000%?%p1%{1}%=%th%el%;
+
+ The <EM>z</EM> 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 <STRONG>ALL_MOUSE_EVENTS</STRONG> class does not include <STRONG>REPORT_MOUSE_POSITION</STRONG>.
+ 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.
</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
- These calls were designed for <EM>ncurses</EM>, and are not found in SVr4
+ These calls were designed for <EM>ncurses</EM>, and are not found in SVr4
<EM>curses</EM>, 4.4BSD <EM>curses</EM>, or any other previous version of <EM>curses</EM>.
- SVr4 <EM>curses</EM> had support for the mouse in a variant of <STRONG>xterm(1)</STRONG>. It is
+ SVr4 <EM>curses</EM> had support for the mouse in a variant of <STRONG>xterm(1)</STRONG>. It is
mentioned in a few places, but with no supporting documentation:
- <STRONG>o</STRONG> the "libcurses" manual page lists functions for this feature which
+ <STRONG>o</STRONG> the "libcurses" manual page lists functions for this feature which
are prototyped in <STRONG>curses.h</STRONG>:
extern int mouse_set(long int);
mouse_info minfo Mi Mouse status information
req_mouse_pos reqmp RQ Request mouse position report
- <STRONG>o</STRONG> the interface made assumptions (as does <EM>ncurses</EM>) about the escape
+ <STRONG>o</STRONG> the interface made assumptions (as does <EM>ncurses</EM>) about the escape
sequences sent to and received from the terminal.
- For instance the SVr4 <EM>curses</EM> library used the <STRONG>get_mouse</STRONG> 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 <STRONG>req_mouse_pos</STRONG>
+ For instance the SVr4 <EM>curses</EM> library used the <STRONG>get_mouse</STRONG> 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 <STRONG>req_mouse_pos</STRONG>
capability.
- Those features required a terminal which had been modified to work
+ Those features required a terminal which had been modified to work
with <EM>curses</EM>. They were not part of the X Consortium's xterm.
- When developing the xterm mouse support for <EM>ncurses</EM> in September 1995,
- Eric Raymond was uninterested in using the same interface due to its
+ When developing the xterm mouse support for <EM>ncurses</EM> 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
+ 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.
- The feature macro <STRONG>NCURSES_MOUSE_VERSION</STRONG> is provided so the preprocessor
- can be used to test whether these features are present. If the
- interface is changed, the value of <STRONG>NCURSES_MOUSE_VERSION</STRONG> will be
- incremented. These values for <STRONG>NCURSES_MOUSE_VERSION</STRONG> may be specified
- when configuring <EM>ncurses</EM>:
-
- 1 has definitions for reserved events. The mask uses 28 bits.
-
- 2 adds definitions for button 5, removes the definitions for
- reserved events. The mask uses 29 bits.
-
- The order of the <STRONG>MEVENT</STRONG> structure members is not guaranteed.
- Additional fields may be added to the structure in the future.
-
- Under <EM>ncurses</EM>, these calls are implemented using either xterm's built-
- in mouse-tracking API or platform-specific drivers including
-
- <STRONG>o</STRONG> Alessandro Rubini's gpm server
-
- <STRONG>o</STRONG> FreeBSD sysmouse
-
- <STRONG>o</STRONG> OS/2 EMX
-
- If you are using an unsupported configuration, mouse events will not be
- visible to <EM>ncurses</EM> (and the <STRONG>mousemask</STRONG> function will always return <STRONG>0</STRONG>).
-
- If the terminfo entry contains a <STRONG>XM</STRONG> string, this is used in the xterm
- mouse driver to control the way the terminal is initialized for mouse
- operation. The default, if <STRONG>XM</STRONG> is not found, corresponds to private
- mode 1000 of xterm:
-
- \E[?1000%?%p1%{1}%=%th%el%;
-
- The mouse driver also recognizes a newer xterm private mode 1006, e.g.,
-
- \E[?1006;1000%?%p1%{1}%=%th%el%;
-
- The <EM>z</EM> 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 <STRONG>ALL_MOUSE_EVENTS</STRONG> class does not include <STRONG>REPORT_MOUSE_POSITION</STRONG>.
- 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.
-
</PRE><H2><a name="h2-BUGS">BUGS</a></H2><PRE>
- Mouse events from <EM>xterm</EM> are <EM>not</EM> ignored in cooked mode if they have
- been enabled by <STRONG>mousemask</STRONG>. Instead, the <EM>xterm</EM> mouse report sequence
+ Mouse events from <EM>xterm</EM> are <EM>not</EM> ignored in cooked mode if they have
+ been enabled by <STRONG>mousemask</STRONG>. Instead, the <EM>xterm</EM> mouse report sequence
appears in the string read.
- Mouse event reports from <EM>xterm</EM> are not detected correctly in a window
- with keypad application mode disabled, since they are interpreted as a
- variety of function key. Set the the terminal's <EM>terminfo</EM> capability
- <STRONG>kmous</STRONG> to "\E[M" (the beginning of the response from <EM>xterm</EM> for mouse
- clicks). Other values of <STRONG>kmous</STRONG> are permitted under the same
+ Mouse event reports from <EM>xterm</EM> are not detected correctly in a window
+ with keypad application mode disabled, since they are interpreted as a
+ variety of function key. Set the the terminal's <EM>terminfo</EM> capability
+ <STRONG>kmous</STRONG> to "\E[M" (the beginning of the response from <EM>xterm</EM> for mouse
+ clicks). Other values of <STRONG>kmous</STRONG> are permitted under the same
assumption, that is, the report begins with that sequence.
Because there are no standard response sequences that serve to identify
- terminals supporting the <EM>xterm</EM> mouse protocol, <EM>ncurses</EM> assumes that if
+ terminals supporting the <EM>xterm</EM> mouse protocol, <EM>ncurses</EM> assumes that if
<STRONG>kmous</STRONG> is defined in the terminal description, or if the terminal type's
- primary name or aliases contain the string "xterm", then the terminal
+ primary name or aliases contain the string "xterm", then the terminal
may send mouse events. The <STRONG>kmous</STRONG> capability is checked first, allowing
use of newer <EM>xterm</EM> mouse protocols such as its private mode 1006.
-ncurses 6.4 2023-1
0-21 <STRONG><A HREF="curs_mouse.3x.html">curs_mouse(3x)</A></STRONG>
+ncurses 6.4 2023-1
2-16 <STRONG><A HREF="curs_mouse.3x.html">curs_mouse(3x)</A></STRONG>
</PRE>
<div class="nav">
<ul>
</ul>
</li>
<li><a href="#h2-RETURN-VALUE">RETURN VALUE</a></li>
+<li><a href="#h2-NOTES">NOTES</a></li>
<li><a href="#h2-PORTABILITY">PORTABILITY</a></li>
<li><a href="#h2-BUGS">BUGS</a></li>
<li><a href="#h2-SEE-ALSO">SEE ALSO</a></li>
projects / ncurses.git / blobdiff