Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!newstop!sun!kimba!hvr
From: hvr%kimba@Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: event-driven X11
Message-ID: <114431@sun.Eng.Sun.COM>
Date: 8 Jul 89 09:29:54 GMT
References: <5303@pt.cs.cmu.edu> <8906231745.AA07649@expo.lcs.mit.edu>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 66

In article <5303@pt.cs.cmu.edu> you write:
>
>with XToolkit i am even worse off.  i must call a never-returning XtMainLoop()
>which prevents me from using the XCheckIfEvent() solution.  so if i want to be
>driven by some other factor AND use XToolkit then my other factor must generate
>the interrupts.  but suppose that that other factor is like X and doesn't offer
>any method to generate interrupts?  this is exactly the situation for my
>project.
>
>so.... please stop telling me that "all X programs MUST/SHOULD be event
>*driven*".

In Sunview, there are three ways to get events from the window system.  1)
implicit dispatching, 2) explicit dispatching, or 3) roll your own.  

The implicit dispatching mechanism allows one to dispatch window events while
getting input via read from some other source such as stdin, a socket, or
a pipe.  This type of input system works well when the program wants to be
getting input from a constant stream and periodically be interrupted with
window system events.

The explicit dispatching mechanism is the most common.  This can be used with
varying degrees of control.  window_main_loop puts the event distribution into
an infinite loop and calls your registered functions when an event happens.
notify_dispatch will dispatch one event each time it is called which allows the
programmer to intersperse notification with code.  The pair notify_start and
notify_stop allow one to affect the window_main_loop in a start and stop manner.

For example, using explicit dispatching, you get the equivalent of SIGIO on some
file descriptor by using the function call notify_set_input_func.  And using
implicit dispatching with either select/read or notify_set_input_func.  The
call to notify_set_input_func tells the notifier that when it gets a SIGIO on
this file descriptor to call your function which then does a read.  If you have
a lot to read, you can just read N bytes and your function will be called again
and again while you still have something to read.  When your reader receives
EOF, you unregister the reader function.

If one wants to by-pass the entire notification scheme, there are functions to
read the events directly; however, beware...there be dragons.

In general, the Sunview notifier is very full-featured.  In addition to
window system events, you can also receive signals, input on a file descriptor,
timers, pass events between clients in the same process, interpose on a
notifier client to change its behavior, receive notification on a process's
death.  So, whatever interrupt the system generates, there is a way to
register a call back function for that interrupt.

The Sunview notifier does apply to X11 applications since this notification
system will be present in the XView toolkit.

A couple of common gotchas with a notification based window system:  1) when
you are in a call back function, all event distribution is suspended until
you exit.  This could be worked around.  You can affect your own concurancy 
by calling yourself N times while saving some state,  (for example, only reading
N bytes as above), or use two processes--one to service the user and the second
to do the main body of work for the application.  2) UNIX and window systems 
are not "real time", this also applies to Sunview.

The Sunview notification system is not perfect; however, it has been worked on
and tested for several years which generally means things improve and become
more stable.  For more details, see chapter 17 of the Sunview Programmer's
Guide (release 4.0).

I hope this broadens your possibilities,

Heather