std input and gui interaction drivers

12.27: adda/arch/std`input:
. in my idealized expression of the mvc pattern,
the designers of apps should never have to
program the details of the user's gui;
they simply write to data structures,
and the user`agents have their favorite ways of
expressing structures graphically;
but what if the app designer
wants to contribute new ways of
graphical interaction ?
. such gui drivers shouldn't get direct access
to the mouse and keyboard (input events);
instead, like unix is designed,
drivers get gui events from std`input;
and, the user`agent is free to
feed the gui driver either the actual input events
or the user`agent's version of input events .
[12.29: for modularity:
. the gui driver's usefulness to some users
may depend on the user`agent's ability to
filter the user's input,
or simulating it with an algorithm;
eg, an adaptation for those with the shakes
might be to filter duplicate inputs .
adde plug-in's:
. the general way to develope the gui
is for adda, the compiler,
to be aware of plug-in's for adde, the editor;
a gui driver is associated with a typemark,
and then when adde is displaying
items of that type,
it lets the associated gui driver
decide how inputs translate into
modifying a value of that type .
. there can also be event-triggered gui drivers
(vs triggered by accessing a certain type)
eg, a selection lasso driver
would be triggered by a mouse-down drag,
and instead of stopping at mouse-up,
it would keep accumulating selection rectangles,
until, say, the enter key was pressed .]