> On Sat, Jun 29, 2019 at 07:49:06PM -0400, Thomas Dickey wrote:
> > On Tue, Jun 25, 2019 at 08:34:33AM +0000, address@hidden wrote:
> > > Currently, one can include STDIN_FILENO in a select(2), and then call
> > > getch()
> > > if input is available on stdin. This allows for a main loop that also wait
> > > on other file descriptors, signals and a timeout. Unfortunataly, the mouse
> > > cannot be included in this select because the _mouse_fd field of the SCREEN
> > > structure is private.
> > >
> > > A workaroud is to have a thread call getch() in blocking mode and then serve
> > > the result on a pipe whose other end goes in the select. But this solution
> > > seems awkward to me, especially considering that STDIN_FILENO is instead
> > > always available to the application, and compared with having a function
> > > like
> > > getmousefd() that returns _mouse_fd.
> > >
> > > This function would be similar to ConnectionNumber(Display *) in XWindow:
> > > it
> > > returns a file descriptor to be used in a select, so that the application
> > > may
> > > then call XNextEvent() or similar if something can be read there. I believe
> > > it is not supposed to be used in any other way.
> >
> > _mouse_fd is only used for the GPM dependency, which is rarely used...
>
> oh, also for sysmouse (likewise, rarely used)
>
> It's not used for xterm protocol or the MinGW port.
On xterm, a mouse event triggers select() on stdin. My idea is: wait for
activity on stdin, on mousefd if >=0, and on any other file descriptor one
wants to read from (pipes, sockets, etc.). In the first two cases, obtain the
event by getch() or wgetch().
So the new function is not needed for xterm, but is necessary for making
select() work the same way on a vt.
Acually, this would be better done on scr->_ifd rather than stdin. This should
also work on MinGW, where _nc_mingw_testmouse() is called on fd =
_nc_get_handle(sp->_ifd).
I attach an example program: it just waits for the first event to come and
terminates. The events are:
- keyboard
- mouse
- data on a named pipe
On xterm, both keyboard and mouse cause select() to terminate on stdin; on vt,
it terminates on stdin and mousefd, respectively. On pipe activity, it
terminates on the pipe file descriptor. As long as mousefd is only used in the
select, and the program makes the same thing in the first two cases, everything
works the same in both xterm and vt.
>
> A more productive approach would be to investigate the wgetch-events
> interface, which is supposed to solve the problem you're concerned
> about...
>
In my example, one could have a thread waiting for activity on the pipe, and
then call fifo_push() to unblock wgetch(). But then the same thread would have
to actually read the pipe, as otherwise its select() would also return the next
time. This creates the additional problem of exchanging data between different
threads. Just returning stdscr->_ifd and stdscr->_mouse_fd seems a simpler
solution to me.
Or maybe I didn't got your suggestion.
waitevent.c