Re: Mouse button handling

[Damien Guibouret]

Anders Juel Jensen wrote:
> With Damien's patch i get a much more responsive interaction - as in,
> now mouse-clicks aren't vanishing into thin air.
>
> That being said, I still get some funny behavior, like getting
> BUTTON1_CLICKED despite only having set mousemask to the PRESSED
> and RELEASED variants.  Attached is my small test program. Sorry for
> the use of panels, but for mysterious reasons I can't get screen output
> without (?!?). It should at least illustrate the _CLICKED problem, and
> if you are lucky enough you might also see a "We got KEY_MOUSE but there
> was no pending event?!?". That one is pretty hard to reproduce - but
> I have gotten it twice while doing heavy mouse workout :P
> Oh, and I to get movements for scroll, and nowhere else.
>
> Also I seem incapable of setting up an xterm
> correctly for mouse position reporting... I tried "xterm -tn
> xterm-1003" with no luck, so I figure I'd better go investigate, and lo
> and behold, running infocmp on both xterm and xterm-1003 showed no
> difference.. err.. this is wrong, right?
>
> ncurses-5.9-patch0 + Damien's patch configured like this:
>   --with-gpm \
>   --disable-termcap \
>   --with-normal \
>   --with-shared \
>   --enable-symlinks \
>   --without-debug \
>   --without-profile \
>   --without-ada \
>   --with-chtype=long \
>   --with-mmask-t=long \
>   --program-suffix="" \
>   --program-prefix="" \
>   --build=x86_64-slackware-linux
>
> What am I doing wrong here?
>
> Happy hacking!
> Anders

Hello,

The BUTTON1_CLICKED event is due to the fact there is a ';' after condition to 
test if there is this event, so the 'A click?!?' message is always displayed.

For the "We got KEY_MOUSE but there was no pending event?!?", this is due to 
_nc_wgetch in lib_getch.c: at line 525 (for 5.9 not patched), it does (not 
considering the preprocessor part):
if (runcount > 0 && ch != KEY_MOUSE) {
                /* mouse event sequence ended by keystroke, store keystroke */
                safe_ungetch(sp, ch);
                ch = KEY_MOUSE;
}
considering that if runcount > 0, there was at least one mouse event. It is not 
wrong but if it is an event that was not set into mousemask it has already been 
discarded. As I said in a previous mail the change in getmouse does that 
behaviour with the patch change from previous behaviour in the fact that using 
getmouse could report ERR when it returns OK previously but with an event user 
did not expect.
A way to avoid that is to add code inside "if" above to check if mouse event is 
one expected by user: if not keystroke can be keep, else it shall be stored to 
set KEY_MOUSE into ch. But I am afraid that there is some other cases where this 
behaviour can be encountered so it is better user of getmouse to check it gets 
OK before using event.
In case getting a not expected event from getmouse instead of ERR is preferred, 
it could be easily retrieved with removing the loop that I added at begin of 
getmouse that checks for event to be set in mousemask.

Regards,

Damien