8.12: adda/cstr/signals/signaling in gui systems:
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .
. as an overview,
our programs are not usually concerned with gui,
rather they are exporting an IPC channel,
and then the gui agent converts channel data into a gui
just like a browser turns html into a gui .
. so, first we're solving the problem of
how a datastructure is being shared with a coprocess:
we send it a link to one of our obj's or tasks,
which is like any other data,
but when its operated on,
the calls are being queued and done serially; [11.10:
using Ada's protected variables idea .]
. next is the gui for the human:
the human's gui agent is
operating such an IPC channel;
and, is translating it into graphics .
[11.10: back to signals:
. the gui agent is mirroring the IPC channel
with a tree of widgets that the user can interact with;
and, widgets are signaling back to the gui agent
whenever a user changes this widget tree,
so that the agent can mirror these changes
in the IPC channel .
. if the user launches a command,
then its operation could change the channel's data;
but we don't know which parts it has changed,
so we have to redraw the user's view .
. some of this drawing will be unnecessary,
and we could avoid doing it if the IPC channel
used a journalling system to point at
all the parts it updated .
. a 2nd use of signals occur in the case where
an object is being modified by multiple users;
not only do we need the journaling system
to show us where the changes occurred;
we also need a signaling system
to show us when they occurred by others .
. the needed signaling system doesn't have to be
generally reusable like the Qt Notification Center;
because, the IPC channeling already defines
who our potential signal recepients are;
and they won't be needing to register any signal handlers;
rather, they need only check their email,
and respond to an IPC channel's heads-up
by reviewing that channel's latest journal entries .]