Re: Advice on mouse handling

Thomas,

I am parsing out both 1000 and 1006 control codes emitted by the guest application and setting up my mouse "driver" accordingly. After working out a bug, my X10 driver works with at least one application but a number of others are not. I am relying on 1006 being sent in order to determine which protocol (driver) I should be talking to the application with. Is it possible that SGR mode is being used even though only code 1000 was emitted by the application (presumably via ncurses)? On a related note, I see that some applications are emitting 1006 even though kmous is set to \e[M ...whether or not that's ncurses or some other decision maker, it seems odd to violate what the terminfo describes.

On Mon, Jul 8, 2019 at 6:48 PM Thomas Dickey <address@hidden> wrote:

On Mon, Jul 08, 2019 at 09:43:26AM -0500, Bryan Christ wrote:
> Thomas,
>
> Thanks for the reply. The application on the reading end is a ncurses
> app. Is there a reason that ncurses would be expecting something like a
> cursor key sequence?

There's more than one xterm mouse protocol; the original one (which you're
using in the sample code) and the newer one. ncurses picks one depending
on the value for kmous:

kmous: '\E[M', '\E[<'.

In the latter case, it looks for this:

SGR (1006)
The normal mouse response is altered to use CSI < followed by
semicolon-separated encoded button value, the Cx and Cy ordi-
nates and a final character which is M for button press and m
for button release.

(I see that it's not very clear in curs_mouse.3x, so there's another to-do)

However, I don't see why one click would work --- it's usually all or none.

> On Sat, Jul 6, 2019 at 3:57 PM Thomas Dickey <address@hidden> wrote:
>
> > On Fri, Jul 05, 2019 at 12:47:04PM -0500, Bryan Christ wrote:
> > > Thomas,
> > >
> > > I've read the xterm documentation you authored and have reviewed the code
> > > in lib_mouse.c in order to add VT200 mouse support to my emulator. The
> > > following code works well on the first mouse click, but subsequent mouse
> > > clicks don't seem to work at all. After putting some debug code inside
> > the
> > > conditional, I can see that each click is indeed firing and the x and y
> > > coords are updating. I'm at a loss as to why writing that string to the
> > > underlying pty works fine once but not thereafter. The guest application
> > > is built on ncurses so it would seem that if the sequence was decoded
> > once
> > > correctly it should be again subsequent times.
> > >
> > > case KEY_MOUSE:
> > > {
> > > if(has_mouse() == TRUE && vterm->mouse == VTERM_MOUSE_VT200)
> > > {
> > > if(getmouse(&mouse_event) == OK)
> > > {
> > > if(mouse_event.bstate & BUTTON1_CLICKED)
> > > {
> > > dynbuf = strdup_printf("\e[M%c%c%c\e[M%c%c%c",
> > > (char)(32 + 0 + 0),
> > > (char)(32 + mouse_event.x),
> > > (char)(32 + mouse_event.y),

rereading this, I'm not sure what might happen here, because there's
no delay between the two escape sequences. ncurses collects mouse
events in a fifo, and combines them to get click, double-click, etc.

A real user will have a real delay.

> > > (char)(32 + 0 + 0x40),
> > > (char)(32 + mouse_event.x),
> > > (char)(32 + mouse_event.y));
> > > }
> >
> > perhaps it's not flushed, or else what's reading it expects a regular
> > ANSI control (like a cursor-key) which ends with a character like 'D' or
> > '~'.
> >
> > > buffer = dynbuf;
> > > }
> > > }
> > > break;
> > >
> > > --
> > > Bryan
> > > <><
> >
> > > _______________________________________________
> > > Bug-ncurses mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/bug-ncurses
> >
> >
> > --
> > Thomas E. Dickey <address@hidden>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
> >
>
>
> --
> Bryan
> <><

--
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

From:	Bryan Christ
Subject:	Re: Advice on mouse handling
Date:	Tue, 9 Jul 2019 10:46:15 -0500