[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mouse button handling

From: Damien Guibouret
Subject: Re: Mouse button handling
Date: Fri, 16 Sep 2011 21:40:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050416

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="" \

What am I doing wrong here?

Happy hacking!


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]