making presentation actions work when no input expected

["William M. York" <York%chuck-jones.ila-west.dialnet.symbolics.com@RELAY.CS.NET>]

    Date: Fri, 24 Feb 89 11:52 EST
    From: SWM@SAPSUCKER.SCRC.Symbolics.COM (Scott McKay)

	Date: Fri, 24 Feb 89 11:07:59 EDT
	From: cogen@XN.LL.MIT.EDU (David Cogen)

	I have used DEFINE-PRESENTATION-ACTION to perform a side effect when the mouse
	is clicked...
	This works as long as the currently selected window is accepting input. 

    You can think of presentation translators as taking place in the "eval"
    part of the "read-eval-print" loop (or you might think of them as acting
    like commands in the CP) , and presentation actions as taking place in
    the "read" part (they actually run in the input editor).  No translation
    of any kind takes place when the process is not waiting for input.

One possible solution to this problem is to make sure that your
application is listening for input more often.  I assume that when your
application is running (i.e. not waiting for input) for long periods it
is busy executing some application-specific computation, and it will
eventually update the display panes with the newly-computed information.
Would it be practical to run these long-duration command bodies in a
background process?  Suppose you were given some better process
management tools (better, that is, than process-run-function).  Tools
that made it easy to synchronize with a background process, to allow the
background to trigger pane redisplay, etc.  The processes could
communicate via shared information in the program instance.  Using the
background process for lengthly calculations would leave the foreground
free to handle other "commands", such as window reconfiguration or data
display format change requests.  Would your application lend itself to
such a scheme?

The underlying premise is that it is probably easier to run command-body
code in a background process and get the synchronization and environment
issues right than it is to run UI-related code (which puts us back in
the bad old days of :mouse-moves code that ran in the mouse process).