gui notification systems

5.18: adde/gui/notification systems:

. all processes can inter-communicate;
but, processes are also hierarchical,
eg, apps represent root processes,
while owning a set of subprocesses;
so, intercommunication happens only between
siblings and ancestors (parents, grandparents, etc).

. the gui display is seen by apps
as a list of pointers to obj's that draw images .
. making an obj gui-visible means
adding a link to this gui list .
. since most app windows are a
tree-like arrangement of objects,
the gui list items are usually trees (lists of lists).
. the first on this list corresponds to
the front-most window;
apps can change the order of this window list
unless barred by the user;
but, of course, the user controls
only the top level of this list,
since the trees underneath belong to
particular apps not the user .
. in either case, it is the owner who decides
who can see or modify their possessions .

. if x.app (an app named x)
gives embedding rights to y.app,
then x.app accepts offers to
list a given item in its own gui sublist;
this allows apps to work together on
generating parts for the same window .
. the default capability is to allow nothing
(no reading and no modification);
so, by default, when reading the gui list,
non-self sublists appear to have no parts,
just a link for contacting the owner .

. the system is following an mvc pattern;
so, when putting an obj in a gui sublist,
what is actually posted there
is an image (view of mvc)
of the obj (model of mvc);
ie, each datatype can draw an image;
and, each time a gui'd object is modified,
this must cause the object to emit a signal
that will result in the obj's gui image being updated .
. finally, a gui image update must
signal to the gui mgt
to recopy that image to the screen buffer
and recopy every overlapping image,
or somehow avoid overwriting overlapping images .
todo: need ideas from QT how to arrange it  .