Re: Advice on mouse handling

[Thomas Dickey]

On Tue, Jul 09, 2019 at 10:46:15AM -0500, Bryan Christ wrote:
> 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.

Well, it _could_ be a program running in a subprocess that's set $TERM to
a different value (such as in screen/tmux).  But also, it could be hardcoded
behavior (not much that I can do about that).  It would be helpful to know
what the application is.

I could make ncurses accept either protocol, but that would have the
drawback that the X10 protocol could send bytes that get in the way
of UTF-8 encoding (which is one of the things that 1006 fixes).
Very likely, some hard-coded applications have their own assumptions
about what would happen in that case (and usually, the assumptions
don't work well - which is why we notice them).

> 
> 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
> >
> 
> 
> -- 
> Bryan
> <><

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

signature.asc
Description: PGP signature