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