=DEann 26-Sep-97 skrifar Steve Lamontr:
>=20
> I think doing this would break the X programming model.
>=20
> [snip]
>=20
> A caveat here -- if you're actually processing during your own signal
> (interrupt) handler, you have to be careful not to disarrange the
> state of X. For instance, as we've discussed on this list before, X
> is not reentrant -- meaning that if your signal interrupts something
> happening down in the bowels of X, you're probably eventually going to
> lose.
>=20
Well, to get it more into perspective, and a better idea of what I was
thinking...
I wrote an application that answers the telephone, through my voice
modem. It determines if the call is voice/data/fax, and returns a signal
to HylaFax if it is data or fax, or handles it in case of a voice call.
The program copies data to the serial port, small blocks at a time, to
ensure a constant steady stream of voice data to the modem when it is
to play messages. It plays a greeting message, over the modem, as well
as over the speakers through NAS audio... it is here, that I would like
to add a small form where if the user on the console presses a single
button, the program would stop the automatic answer and lapse into a
telephony routine, where I can speak through the modem with the
microphone (In case I'm home or want to answer ;-)
The way I thought this, was that a single form would appear, and I
would register a handler routine. Now, the main loop of the program
would continue as normal, but when the mouse was over my form, an event
would trigger that was handled by the handler routine. Change the event
status of the modem io, making it stop after the current block transfer,
and lapse into telephony.
Now, as someone suggested, I can fork a child process or use linuxthrea=
ds
to run a child process which will poll the GUI interface. But, it seems
more logical to me, that with a single X window that the X interface shou=
ld
call an event handler when an event is triggered (like a mouse clicks on
a button on my form), much like interrupt driven I/O (my handler is calle=
d
when there is I/O)... instead of the program's main loop sitting in an
internal loop waiting for an event to trigger (polling).
As I see it, I have one keyboard, one mouse and one screen (usually :-)=
,
and thus I only need one program watching these input devices. When an
input occurs (a basic input event, like a mouse position, or a more
sophisticated one like a mouse triggering a form) it can interrupt the
process that has the registered input focus of that part of the screen.
Well, at least I think so :-)
-------------------------------------------------------------------------=
---
Orn Einar Hansen oe.hansen@oehansen.pp.se
oehansen@daimi.aau.dk
voice+fax; +46 035 217194
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/