🚀 go-pugleaf

As I understand it, GEM doesn't really have the concept of a window being active or
not being active for input.  Instead you just have the currently active "process"
which should be sitting in an event wait system call waiting for, among other things,
input messages.  That "process" can then apply the events to any window that it wants.

If a "process" wants to have output going to multiple windows "simultaneously", that's
up to the "process".

The only complication here are desk accessory "processes".  While they can try to also
wait for input events in addition to the foreground "process", from the experiments
I've run it doesn't seem to be deterministic as to which process will get the input.
So desk accessory "processes" normally just wait for activation events, and when they
are activated and in control of system resources they then can wait for input.

I use the term "process" above because GEM is a limited multi-tasking system.  It
(on the Atari ST) supports one foreground process, and up to six background processes.
The foreground process is the desktop, or a program run from the desktop.  The
background processes are desk accessories.  Process switching only occurs when a
process voluntarily waits; i.e. there is NO preemptive scheduler.

Note that this "multi-tasking" is implemented only in the GEM AES module.  This is
why desk accessories are not available from a non-GEM program; a non-GEM program
never enters GEM AES, thus it never does an AES event wait; thus AES never gets a
chance to schedule a desk accessory (background) process.

dgc