Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!decuac!shlump.nac.dec.com!engage.dec.com!lbduck.dec.com!schoeller
From: schoeller@lbduck.dec.com (Dick Schoeller)
Newsgroups: comp.windows.x
Subject: Re:  help (with a popup prompt design)
Message-ID: <1264@engage.dec.com>
Date: 18 Aug 89 20:18:46 GMT
References: <8908180033.AA00450@expo.lcs.mit.edu>
Sender: news@engage.dec.com
Organization: Digital Equipment Corporation, Maynard, Massawhat?
Lines: 41

In article <8908180033.AA00450@expo.lcs.mit.edu>, aparisi@BBN.COM
(Corporal Jones) writes:
> Actually, there may be a very good reason to nest an event loop.
> 
> Say you need to implement a command-driven style of interaction within a
> toolkit application.  I know we are trying to avoid this at all costs in
> the Brave New World of the future, but there are some large, monolithic,
> command-driven applications out there that people are converting to X.
> Often a first step in the conversion is to provide GUI front ends to a
> subset of the functionality, and provide a command-driven escape hatch (for
> example, a DECWindows Command widget) for the non-converted functionality.
> 
> In this scenario, the application will want the main thread to be blocked
> on a command read until a command is actually entered.  The way to do the
> block is to nest an event loop (NOT XtMainLoop, naturally-- as you said,
> how will it return?) in the procedure that does the read from the command
> widget.  The event loop would terminate when a command is entered.  (It
> probably detects this using a semaphore that is set by the command widget's
> commandEntered callback).
> 

Command driven applications are the easiest to port to event driven
(after all, events are just graphical commands  8^{).  There is really
no need to go through all the above mess about blocking and multiple
threads.   There is usually no reason to use some other looping structure
than XtMainLoop either. 

The simplest approach is to take the routines that would have been called
in response to the original command and put them in the callback for the
applicable widget.  If there are any operations which have not been moved
to a specific widget, you simply parse them out in the callback from a
command entry widget.

The applications that ARE hard to deal with in the X Toolkit are AST driven
applications or application driven users.  These are the situations where
XtMainLoop falls short.  (Esp. AST driven since Xt is not AST re-entrant).

Dick Schoeller			| schoeller@gvriel.enet.dec.com
Digital Equipment Corporation	| 508-493-1670 
129 Parker Street, PKO3-1/H21	| 
Maynard, MA 01754-2571		| This author has no opinions to disclaim!