1

I am able to echo -e "\e[?1003h" and watch as my terminal gobbles up mouse movement events like candies but curses doesn't seem to want them at all. I looked at

Mouse movement events in NCurses

but it would appear that this issue was resolved by changing the TERM env, which would not help me because my terminal is indeed responding to mouse move events, however, ncurses is not. Here's something I have tried (This code came almost entirely from the other question):

#include <ncurses.h>
#include <assert.h>

int main(){
        int ch, count=0;
        mmask_t old;

        initscr ();
        noecho ();
        cbreak ();
        mousemask (ALL_MOUSE_EVENTS | REPORT_MOUSE_POSITION, &old);
        keypad (stdscr, TRUE);
        printf("\033[?1003h");

        while ((ch = getch ()) != 'q')
        {
          count++;
          if (ch == KEY_MOUSE)
          {
             MEVENT event;
             assert (getmouse (&event) == OK);
             mvprintw (0, 0, "Mouse Event!\n");
          }
          mvprintw (1, 1, "Event number %4d",count);
          refresh();
        }
        endwin();

}

Additional information and warning:

This program actually accomplishes being able to detect mouse movement AFTER execution. This can be reversed with the command echo -e "\e[?1000h"

Scheff's Cat
  • 19,528
  • 6
  • 28
  • 56
AlgoRythm
  • 1,196
  • 10
  • 31
  • 2
    By default `printf()` is line-buffered: the C library caches the data internally, until a newline is seen. To fix, use `printf("\033[?1003h"); fflush(stdout);`. Similarly, add `printf("\033[?1000h"); fflush(stdout);` before `endwin();` to restore default behaviour when the program exits. – Nominal Animal Dec 04 '18 at 04:44
  • @NominalAnimal Please write this as an answer and I will accept it. I was unable to find this anywhere during my research, thank you so much :) – AlgoRythm Dec 04 '18 at 04:48

1 Answers1

3

While printf and curses write to the standard output, ncurses will not flush stdout since it does its own buffering. As mentioned in ncurses 6.0 release notes (August 2015):

Output buffering provided a further, but worthwhile distraction. A bug report in 2012 regarding the use of signal handlers in ncurses) pointed out a problem with the use of unsafe functions for handling SIGTSTP. Other signals could be addressed with workarounds; repairing SIGTSTP required a different approach. The solution required changing internal behavior of the library: how it handles output buffering.

Now ncurses buffers its own output, independently of the standard output. A few applications relied upon the library's direct reuse of the standard output buffering; however that is unspecified behavior and has never been a recommended practice. Identifying these applications as well as refining the change to permit low-level applications to work consistently took time.

While the example may happen to work if the printf call is followed by a fflush(stdout), there is no guarantee that will work indefinitely, since there is no need for ncurses to send its mouse-initialization until the getch call. The recommended way to work with ncurses is to put that information into a terminal description, letting ncurses decide when to make changes to the screen.

There is an example in the ncurses terminal database already: xterm-1003

Community
  • 1
  • 1
Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
  • Fully agreed. Because of exactly this, having the `printf()` and `fflush(stdout)` before the `mousemask()` call won't usually work (because `mousemask()` overrides the mode, per terminal config). Of course, running the example as `TERM=xterm-1003 ./example` will work in many terminal emulators (`gnome-terminal`, `xterm`, `mate-terminal`, `lxterm`, `uxterm`, and `terminator` at least), although not all seem to support horizontal scroll wheel. – Nominal Animal Dec 05 '18 at 04:31