[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mouse button handling
Re: Mouse button handling
Tue, 13 Sep 2011 16:56:15 -0400 (EDT)
On Tue, 13 Sep 2011, Damien Guibouret wrote:
Thomas Dickey wrote:
On Tue, 13 Sep 2011, Anders Juel Jensen wrote:
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
Thanks for the help offer. I think it could be mostly for compatibility issue
with terminal/OS I do not have.
For the line wrapping problem, I sent it as a mail attachment, so I do not
think mailer can reformat it. I did it against the 5.9 version (no patch)
that could be loaded on GNU.org site.
If you want I could sent it to you gzipped such as there will be no line
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.
For information GPM can support it with using GPM_DRAG | GPM_MFLAG | GPM_MOVE
into gpm event mask, but the treatment of the corresponding events needs to
be added when getting a GPM event (or REPORT_MOUSE_POSITION can be just set
as default event in case not getting one of the others). According to the
documentation I have (but it's an old one) GPM_DRAG and GPM_MFLAG are related
to motion with button pressed (first during motion, second on button release)
and GPM_MOVE to simple motion.
I'm aware of that - but the calling interface style needed to handle that
was (as I recall...) requiring a handler process (something what's used
for EMX). All of GPM's documentation is old, by the way.
grumble: Its alternative xterm interface as well is only a nuisance, both
because it doesn't follow that style, as well as for symbol interferance,
Thomas E. Dickey
Re: Mouse button handling, Anders Juel Jensen, 2011/09/12