nanogui: Re: Ideas on Nano-X event handeling and API (was: Re: Nano-X on X )
Subject:
RE: Ideas on Nano-X event handeling and API (was: Re: Nano-X on X
)
From:
Greg Haerr ####@####.####
Date:
24 Nov 1999 20:24:03 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB076A75@NBA-SLAM.CenSoft.COM>
: Some thoughts on the event handeling architecture of Nano-X
: and multiple main-loops in programs in general.
: By Morten Rolland, Screen Media, ####@####.####
Morten,
I read your document on the event handling in Nano-X. Actually,
all it appears you're looking for is the ability to register other file
descriptors in the client select() loop.
I have already hacked a version of this functionality in v0.86,
which you should have (and yes, it's a big hack, but the API will remain
the same). This was required in order to implement the terminal emulator
functionality, where the nano-X client needs to read the socket descriptor
to the Nano-X server, as well as test for i/o on the pseudo-terminal fd.
I added an api called GsRegisterInput(int fd) that takes an fd and
adds it to the internal select() loop. GsUnregisterInput(int fd)
unregisters
it. When there's i/o on the fd, a GR_EVENT_TYPE_FDINPUT event
is sent thru the GrGetNextEvent() event return.
Since this was a quick hack, I only allow for one fd currently, and
I don't return the fd in the EVENT_FDINPUT. But it all works, and I use
it to make the mwin/src/demos/nanox/nterm.c terminal emulator work.
Perhaps you should take a look at it. The only other mod would be
associating
a timeout value with the fd, which currently isn't implemented. (please
suggest
an api).
I prefer this method, but I could as well expose portions of the
client main loop to the programmer. The reason I don't today is that nano-X
isn't limited to systems running select(). We want to be able to handle
this condition on other operating systems as well.
Greg
