ANNOUNCE - graphics package

[Nigel.Head@REDACTED]

> Defining the standard widget set for #1 is (should be) the same thing as
> building a non-standard one. The point is to design the core framework so that
> this is easily done.

I beg to differ!  I believe the standard widget set for type #1 should offload
as much as possible of the intellectual and practical effort needed for
application implementation (and therefore probably flexibility) from the
application implementer whereas the #2 approach should expose all kinds of
customisation possibilities and hooks etc., at the cost of having a bigger
intellectual footprint.

I guess maybe the first case could be seen as a supplementary wrapper around the
second (in one possible implementation approach, at any rate) but I believe
there are fundamental architectural issues at stake here, for example:

+ the application design approach the widget set is designed for -- event driven
with hooks, concurrent etc

+ the nature of the interface made available -- grpahical, canvas related or
functionally oriented

+ the location (in process terms) of possible customisation logic (assuming for
the moment that we're headed for some form of client/server setup, if only to
avoid access conflicts to the lowest level hardware used for the GUI.  This is
kind of like the difference between postscript printers and the windows GDI
thingy's maybe?

Perhaps I've misunderstood the topic of the your original mail though? To avoid
getting wires crossed and wasting bandwidth, I'll rest my case here unless
anyone really wants to continue in private mails.

N.