Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!apple!sun-barr!newstop!sun!kimba!hvr
From: hvr@kimba.Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: Forcing application to process events
Message-ID: <131133@sun.Eng.Sun.COM>
Date: 2 Feb 90 04:07:31 GMT
References: <9002011609.AA05640@ATHENA.MIT.EDU> <2654@bacchus.dec.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 100

In article <2654@bacchus.dec.com> klee@decwrl.dec.com writes:
>In article <9002011609.AA05640@ATHENA.MIT.EDU>,
>Matthew.Diamond@MAPS.CS.CMU.EDU writes:
>> The problem is that these applications were not written to the event-driven
>> model.  I can process events whenever my code is called (most user I/O is
>> handled by me, since I am replacing keyboard procedures with code that
>accepts
>> input from the mouse too).  But there are times when my code is not being
>> called and the application's display freezes for a while.
>
>Two possible solutions are:
>
>1.  Catch and dispatch events yourself, and live with non-updated
>displays when you can't catch events.
>
>2.  Create a second process to do X stuff using a normal X event loop
>and communicate with the main application using sockets, pipes, or
>ptys.  Examples of this method include xmh, xdbx, and even xterm.

3.  Use the XView toolkit.  The XView notifier supplies a function which
is tailored to your needs, notify_do_dispatch().  

The basic idea is to read from some file descriptor (perhaps stdin) and
continue to process window events.  I've included a short example program
from the O'Reilly XView Programmer's Manual to illustrate a very simple
case.  This example can be found on line with the XView toolkit source,
distributed with X11R4.

The XView notifier provides other functionality such as notification on
signals, timers, input pending on any file descriptor: sockets, pipes, files;
child process death, and more.

Heather 

------------------------

This example is not very interesting, but it does show that you can get
input from a file descriptor, do something with it, and still process
window events.

/*
 * ntfy_do_dis.c -- show an example of implicit notifier dispatching
 * by calling notify_do_dispatch().  Create a frame, panel and "Quit"
 * button, and then loop on calls to read() from stdin.  Event
 * processing is still maintained because the Notifier uses it's own
 * non-blocking read().
 */
#include <stdio.h>
#include <xview/xview.h>
#include <xview/frame.h>
#include <xview/panel.h>

Frame frame;

main (argc, argv)
int argc;
char *argv[];
{
    Panel panel;
    char  buf[BUFSIZ];
    int   n, quit();

    xv_init (XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL);

    frame = (Frame)xv_create (NULL, FRAME,
        FRAME_LABEL,    argv[0],
        XV_WIDTH,       200,
        XV_HEIGHT,      100,
        XV_SHOW,        TRUE,
        NULL);

    panel = (Panel)xv_create (frame, PANEL, NULL);

    (void) xv_create (panel, PANEL_BUTTON,
            PANEL_LABEL_STRING,         "Quit",
            PANEL_NOTIFY_PROC,          quit,
            NULL);

    /* Force the frame to be displayed by flushing the server */
    XFlush(xv_get(frame, XV_DISPLAY));

    /* tell the Notifier that it should use its own read() so that it
     * can also detect and dispatch events.  This allows us to loop
     * in this code segment and still process events.
     */
    notify_do_dispatch();

    puts("Frame being displayed -- type away.");
    while ((n = read(0, buf, sizeof buf)) >= 0)
        printf("read %d bytes\n", n);

    printf("read() returned %d\n", n);
}

int
quit()
{
    xv_destroy_safe(frame);
    return XV_OK;
}