Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!lll-winken!arisia!janssen@holmes
From: janssen@holmes (Bill Janssen)
Newsgroups: comp.windows.x
Subject: Re: help (with a popup prompt design)
Message-ID: <2584@arisia.Xerox.COM>
Date: 19 Aug 89 00:28:34 GMT
References: <3982@ncar.ucar.edu> <8908151941.AA26642@expo.lcs.mit.edu> <2523@arisia.Xerox.COM> <445@paperboy.OSF.ORG>
Sender: news@arisia.Xerox.COM
Reply-To: janssen@holmes (Bill Janssen)
Organization: PARC.Xerox.COM
Lines: 43
In-reply-to: dean@osf.osf.org (Dean Anderson)

In article <445@paperboy.OSF.ORG>, dean@osf (Dean Anderson) writes:
>In article <2523@arisia.Xerox.COM> janssen@holmes (Bill Janssen) writes:
>>...
>>creation routine prematurely.  To get around this, recursively call the
>>main loop, and have the callback for the button return from the recursive
>...
>Recursively call XtMainLoop?  How do you propose to get XtMainLoop to
>return? (Without using setjmp) I think the point of what Donna
>...

Well, I confess that I don't use the vanilla XtMainLoop.  My callback
routines return a boolean which indicates to the event dispatcher whether
or not to return from the event dispatching loop.  Thus my pop-up
confirmers can pop up the widget and call the event dispatching loop.
When the event loop returns, the application knows that the pop-up
structure contains the appropriate state (having been stored there by
the callback for the pop-up, which returned "return-from-event-loop"
to the event dispatching routine).

This is equivalent to the schemes being posted here and there, except
that the user does not have to re-write the event dispatching loop for
each confirmer.  In addition, my dispatcher also looks for input on
other streams, not just the X stream, so that the whole application is
not locked up just because the interface is.

There are objections to this approach, along the lines of "The
user should not be able to do anything until the confirmer has been
dealt with."  I think that is the worst kind of wrong-headed thinking,
probably due to inexperience with confirmer systems.  The user should
be able to investigate the environment before making an informed response
to the confirmer.  This means that they should be able to pop up windows,
look at files, etc.  I'll agree that there needs to be some attention
focussing method, so that the confirmer doesn't get forgotten, but it
should *never* block other input.

On the other hand, I can imagine an implementation of a blocking
confirmer that uses a re-entrant dispatching loop...

Bill
--
 Bill Janssen        janssen.pa@xerox.com      (415) 494-4763
 Xerox Palo Alto Research Center
 3333 Coyote Hill Road, Palo Alto, California   94304