bug-ncurses
[Top][All Lists]
Advanced

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

Re: Advice on mouse handling


From: Pavel Stehule
Subject: Re: Advice on mouse handling
Date: Wed, 10 Jul 2019 20:25:53 +0200



st 10. 7. 2019 v 20:21 odesílatel Pavel Stehule <address@hidden> napsal:


st 10. 7. 2019 v 19:53 odesílatel Bryan Christ <address@hidden> napsal:
Pavel,

Using the interfaces that ncurses provides is pretty straight forward.  As a ncurses based terminal emulator though, I have to translate things like BUTTON1_PRESSED into an encoded sequence that ncurses (as part of pspg) reads and then re-interprets as BUTTON1_PRESSED inside your application.  Unfortunately, there are about 5 different "standards" for doing this and no 2 applications are behaving exactly the same.

mc is working almost everywhere and doesn't support all standards. It supports XTERM escape sequences or Linux terminal sequences.

The mouse is working well on this project https://gitlab.com/klamonte/lcxterm

there is interesting reference to application vttest https://invisible-island.net/vttest/

Pavel


Maybe it helps

Pavel


On Wed, Jul 10, 2019 at 12:33 PM Pavel Stehule <address@hidden> wrote:
Hi

st 10. 7. 2019 v 17:24 odesílatel Bryan Christ <address@hidden> napsal:
The applications that work correctly (so far) are "pspg" and "nano".  The two that don't work (and can't explain why) are "ranger" and "tig".

I use (pspg) ncurses mouse API. Lot of Linux applications (like mc) uses ncurses for presentation, but for mouse uses gpm https://www.linuxjournal.com/article/4600

some operations like drag & drop doesn't work well on ncurses mouse API, and popular is using mix of libgpm and ncurses. But now I am looking to code, and it support XTERM mouse too (directly via tty)

so just maybe the tested applications doesn't expect mouse support in your terminal emulations.

Regards

Pavel
 

On Wed, Jul 10, 2019 at 4:58 AM Thomas Dickey <address@hidden> wrote:
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


--
Bryan
<><
_______________________________________________
Bug-ncurses mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ncurses


--
Bryan
<><

reply via email to

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