[Top][All Lists]

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

Re: Mouse button handling

From: Thomas Dickey
Subject: Re: Mouse button handling
Date: Mon, 12 Sep 2011 19:00:40 -0400 (EDT)

On Tue, 13 Sep 2011, Anders Juel Jensen wrote:

On Sat, Sep 10, 2001 at 18:39:01 -0400, Thomas Dickey wrote:
On Thu, Sep 08, 2011 at 12:56:23AM +0200, Damien Guibouret wrote:

Here is the updated diff that adds the mouse event queue compaction
to what I already sent. In addition to that, getmouse checks if event
is in requested mask or not as there could be cases where KEY_MOUSE
is returned without the _nc_mouse_parse function being called (if
_nc_mouse_inline returns FALSE). If it is not in the mask it checks
previous event until getting a requested one or an invalid event (in
this last case it returns ERR).
I modified also the test/ncurses.c also to dump the whole queue when
a mouse key is detected.

hmm - some of it is interesting.  But after applying the change, it's
still not working properly for me.  So my patch tonight reverts the
(relatively small) change from early 2010 which is the basic issue, and
we can pick apart this patch.

Generally what I saw: the display in test/ncurses in response to
(wheel-mouse-up) is clearing parts of the lines.  The "*" expected to
show in response to mouse movement for TERM=xterm-1003 is not showing
(most of the response lines are blank).  Reading through the changes,
it seems that you might still be assuming that detail about 64 vs 96 is
incorrect.  But I'm testing with xterm in the modes that the wheel
mouse and any-event logic are designed for...

However, the queue-draining aspect is related to the change I'm
temporarily reverting.  So that's an area to explore.

I think that if I can guide you toward setting up the same testcases,
then the integration process will go smoother.  It would also help if
the patch were refactored into several phases, each of which would make
some specific improvement that could be tested.

I am very interested in this development, as my project is completely
shot down by the lack of accurate mouse events (especially movement).

if you need help testing your patches before you submit them,
just ship them my way and i will give them a go. Beware of line wrapping
when you inline patches, as the previous one you sent doesn't apply for
me, despite the best of my efforts to un-break it. Are you sure this is
against 5.9-patch0?

I didn't get rejects against my current version - but am going slowly
since there's a lot of change to check over.

To be sure I don't make a fool of myself when testing around
with this I need a bit of clarification, as the curs_mouse(3X) is a
little bit vague on exactly how REPORT_MOUSE_POSITION is supposed to

It's vague because there was no pre-existing implementation to refer to when that manpage was written, originally in 1995. That didn't take into account wheel mice for instance, since support for those wasn't "anywhere" til more than a year later, iirc, and 4 buttons seemed like enough. (A wheel mouse is interpreted as buttons 4/5, and seems to be far more common than 4-button or 5-button mice).

The gpm interface didn't support the report- or all-events stuff; until xterm provided the any-event stuff in 1998, there was nothing to extend.

And (referring to NEWS and terminfo.src), ncurses didn't support that until I added the "xterm-1002" and "xterm-1003" entries to provide a basis for discussion at the beginning of 2002. I could have made the manpage
more explicit at that point, but left it as is, in case someone offered
a similar-but-different implementation.

Should it a) generate KEY_MOUSE under any/every circumstance when the
mouse has moved to another character cell, or b) only generate
KEY_MOUSE for movements while a button is pressed?

xterm has modes for each - which can be demostrated using TERM=xterm-1002 (button) and TERM=xterm-1003 (any-event). One drawback to those is that they put xterm in that mode consistently - there's no feature to tell it to activate those modes only when the any-event or position reporting are wanted.

Some other terminal emulators recognize the corresponding mouse controls, but I don't have a table at hand to report if those do/do not produce unnecessary events when the movement is within a cell (or whether they
encode things just as ctlseqs.ms says).

My own tests says a), but whenever i have had the luxury of actually
getting anything to report back it has been more of a fluke than
something reproducible.

When I test it, it seems to work.  I wouldn't find it usable over a slow
connection, but it seems usable on a local machine.

The wheel mouse (essentially the extended mouse feature) is less usable, since I've no wheel mouse with smooth movement - seems most vendors think it ought to bump along...

Thomas E. Dickey

reply via email to

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