Bill-Gray/PDCursesMod

mousemask, mouse wheel - different behave than ncurses

okbob opened this issue · 7 comments

okbob commented

I am author of pspg https://github.com/okbob/pspg. It was designed against ncurses, and now I try to port it for pdcurses. I use pdcurses for VT on Linux. Today I found one small issue:

I use mousemask, and I had to little bit different setting for pdcurses (it requires MOUSE_WHEEL_SCROLL flag)

#if NCURSES_MOUSE_VERSION > 1

<--><-->mousemask(BUTTON1_PRESSED | BUTTON1_RELEASED |
<--><--><--><-->  BUTTON4_PRESSED | BUTTON5_PRESSED |
<--><--><--><-->  BUTTON_ALT | BUTTON_CTRL |

#ifdef PDCURSES

<--><--><--><-->  MOUSE_WHEEL_SCROLL | REPORT_MOUSE_POSITION |

#endif

<--><--><--><-->  (opts.xterm_mouse_mode ? REPORT_MOUSE_POSITION : 0),
<--><--><--><-->  NULL);

is it expected behave?

GitMensch commented

A that part was missing in your question: you did define PDC_NCMOUSE, didn't you?

okbob commented
Bill-Gray commented

There are some weirdnesses in handling the mouse wheel in ncurses, caused in part by mmask_t being a mere 32 bits. Some comments on the problems here. I had to do some odd things in the code to allow for the possibility that ncurses couldn't return a wheel-up event. We switched PDCursesMod to default to 64-bit mmask_ts a while back.

okbob commented

I don't understand to implementation part. Just if pdcurses provides an compatibility with PDC_NCMOUSE, then it is surprising so this doesn't work by default. Maybe you can in compatibility mode implicitly set MOUSE_WHEEL_SCROLL when BUTTON4_PRESSED are BUTTON5_PRESSED set. Note - MOUSE_WHEEL_SCROLL is not in ncurses.

Bill-Gray commented

Um. I see your point; if you've #defined PDC_NCMOUSE, you would reasonably expect full compatibility with ncurses, including the shortcomings of ncurses.

That does open up some problems. "Fixing" this would mean we'd have the same problems as ncurses (poor wheel handling, no tilt-wheel handling) and would break the current binary compatibility. The need for compatibility with what PDCursesMod does now argues in favor of three options:

(1) the default scenario where PDC_NCMOUSE isn't #defined;
(2) The current scheme where PDC_NCMOUSE being #defined means you get something pretty close to matching ncurses behavior, except that you can read the mouse wheel and mouse movement events;
(3) A new option in which we just try to match ncurses, right down to places where it's limited by trying to fit all events into 32 bits.

GitMensch commented

I love that plan and suggest for 3: PDC_NCMOUSE_LIMITTED or something like that.

okbob commented