nc_getmouse() does not queue events (ncurses incompatibility)

[rhaberkorn]

In ncurses getmouse() actually delivers events from its own queue, so you should call it repeatedly for every KEY_MOUSE:

MEVENT event;
while (getmouse(&event) == OK)
    /* process event... */

If you do the same in PDCursesMod, your program will hang since it always returns OK and delivers the same mouse event repeatedly.

A workaround is obviously some #ifdef __PDCURSES__ magic.

[Bill-Gray]

A fair point (applies to 'upstream' PDCurses too, so possibly of interest to @wmcbrine as well).

The 'real' ncurses getmouse() returns OK if an event was queued and its information copied to the MEVENT structure to which you provided a pointer. If the queue is empty, ERR is returned and the structure is unmodified. A queue of eight mouse events is stored.

In PDCurses or PDCursesMod, as you note, you always get OK returned. (The only way to get ERR is to pass a null pointer or to not have PDCurses* initialized.) We basically have a "queue" of one mouse event, and don't check to see the state of that "queue".

I was going to say that fixing this would require changes to code inside each platform, and would take years and cost millions of lives. However... I think each call to nc_getmouse() could check, say, the (internal) SP->Mouse_status.x variable to see if it's equal to, say, -42, meaning "nothing queued". If it is, no event is queued and we return ERR.

If not, we do have a queued event, copy it to the supplied event struct, and then set SP->Mouse_Status.x = -42. We will then return ERR to subsequent nc_getmouse() requests, until a mouse event really does occur and that x-coordinate is set to a (presumably non-negative) number.

I don't have code on hand to actually test this. But it sounds as if you do, and the following patch should do the trick. (We also do the 'no mouse event queued' resetting when mousemask() is called, to ensure proper initialization the first time nc_getmouse() is called.) Click here for the modified mouse.c.

diff --git a/pdcurses/mouse.c b/pdcurses/mouse.c
index a27d978e..cd934587 100644
--- a/pdcurses/mouse.c
+++ b/pdcurses/mouse.c
@@ -297,6 +297,7 @@ bool mouse_trafo(int *y, int *x, bool to_screen)
 #define BUTTON_MOVE_EVENTS (BUTTON1_MOVED | BUTTON2_MOVED | BUTTON3_MOVED \
                           | BUTTON4_MOVED | BUTTON5_MOVED)
 #define ALL_MOVE_EVENTS  (BUTTON_MOVE_EVENTS | REPORT_MOUSE_POSITION)
+#define NO_MOUSE_EVENT        -42
 
 mmask_t mousemask(mmask_t mask, mmask_t *oldmask)
 {
@@ -317,6 +318,7 @@ mmask_t mousemask(mmask_t mask, mmask_t *oldmask)
 #endif
 
     mouse_set(mask);
+    SP->mouse_status.x = NO_MOUSE_EVENT;
 
     return SP->_trap_mbe;
 }
@@ -341,12 +343,13 @@ int nc_getmouse(MEVENT *event)
 
     assert( SP);
     assert( event);
-    if (!event || !SP)
+    if (!event || !SP || SP->mouse_status.x == NO_MOUSE_EVENT)
         return ERR;
 
     ungot = FALSE;
 
     request_mouse_pos();
+    SP->mouse_status.x = NO_MOUSE_EVENT;
 
     event->id = 0;

If this works, I'd say it fixes the issue rather cheaply.

In PDCursesMod, I started extracting the logic for mouse handling into the common/mouse.c code, currently used on the VT, WinGUI, WinCon, and x11new platforms (and to be extended, I hope, to all the platforms). The motivation for that was that mouse handling is done in a variety of ways on each platform, even though much of the logic in how you synthesize clicks and double/triple clicks from press/releases is the same. However, I did have in mind the possibility of implementing a mouse event queue á là ncurses.