🚀 go-pugleaf

ZoomIdle Commentary

There are some assumptions inherent in the code.  These are not
always explicitly documented; I discuss them here.  This discussion
applies both to the Rascal and the LightspeedC source versions.

When ZoomIdle is opened, a window is put up over the screen.  The
portRect of the Window Manager port is used so it will work for a
screen of any size.  The visRgn of the port must be set to the entire
screen or drawing will only take place below the menu bar.  Then
ZoomIdle waits.

Two event types are processed:  activate and mouse down.  accRun
messages are also processed.  (accRun code chooses a rectangle randomly
and zooms to it; that code is not triggered until an activate event for
the window is received.)  Since the Event Manager reports window
deactivation before window activation, we know, when the activate event
arrives, that the previous active window (whatever it was) has been
deactivated and its owner did whatever was necessary to respond to
that.  ZoomIdle clears the menu bar to prevent the main application
from allowing menu item selection, paints the screen black, and sets
the state so that zooming begins (i.e., so that accRun messages aren't
ignored).

Mouse clicks in the menu bar are not reported to ZoomIdle, because
applications typically pass the click to MenuSelect to track the mouse
until the button is released.  With the menu bar cleared, MenuSelect
just waits until the mouse button is released.  The effect is simply to
pause the display while the button is down.  (In particular, ZoomIdle
can't be selected again; that's why there isn't any check in the code
to see if the driver is already open.  Normally, it's dangerous not to
make this check.)

Mouse clicks below the menu bar are reported to ZoomIdle, and cause
termination.  The window is destroyed and the menu bar is restored.
Note that there is no check to see if the menu bar actually needs
restoring.  It is reasonable to ask whether this is valid.  For
instance, if the user clicks the mouse after initiating ZoomIdle but
before the window comes active, will there be any menu bar to restore?
Yes, because ZoomIdle takes advantage of the fact that the perceptual
mechanisms of the Macintosh operating system induce a distortion of
temporal reality; events are not reported in chronological order but in
priority order.  Since activates are higher priority than mouse clicks,
no matter when the user clicks the mouse, ZoomIdle can never become
conscious of the click until after the activate event is received.
Hence, it *must* be true that the menu bar needs restoring when the
mouse click handling code is invoked.

The drawing pattern and mode for zooming are set to gray and patXor,
respectively.  ZoomIdle builds its own gray pattern because, as a DA,
it doesn't access off A5.  I don't know what that means, except that
the normal QuickDraw globals can't be used.