It's been my feeling for some time that it should be possible for a
Scheme programmer to create windows with menus, buttons, and whatnot,
with a reasonable expectation that the details of implementation can
be left to low level drivers.
Furthermore, the Scheme programmer should be able to write simple code
to do simple things. The code should be simple but the implementation
can be complex. At the high level I don't care whether the widget I'm
handling is written in C, C++, Java, Common Lisp or Scheme. I don't
want to have to care whether my code is running on native Windows,
Cygwin, X, Macos or a cellphone GUI. I don't want to have to care
whether the rendering library is Cairo or SDL. These are
inconsequential fripperies and unwanted dependencies that, if I let
them, will seal my code into a tomb as the years go by.
So it seems to me that the way to produce really good, durable and
reliable Scheme code for GUI programming is to concentrate on a good
high level design.
What I suggest here won't satisfy the requirements of game designers,
or programmers who think the GIMP needs to be rewritten in Scheme, and
it might even fall short of what most people would expect of a modern
GUI. This is because I think we already have enough Window managers,
skin systems, game toolkits and the like, and nearly all the
successful ones are written in a low level language. Rather than
duplicate that work, these suggestions are intended to enable a Scheme
programmer to write an event-controlled, graphical user interface so
that he can communicate with the user in a way that the user finds
intuitive. and to do so without tying him to a particular brand of
GUI.
Eventually I will have to wade deeply into all the popular GUI designs
and come up with one that describes the basics of all of them to a
level of detail that would be useful to a high level programmer. But
for now I'll list some of the things that I think are required in a
useful high level GUI design for Scheme.
* Geometry: the dimensions of each display device must be available to
the high level program. Both pixels and if physical dimensions.
** If the latter are not available to the driver, it should provide
intelligent estimates and say so.
** The dimensions of GUI objects controlled by the program should be
the size requested by the program, or a reasonable approximation
thereof.
* Color: a reasonable level of color control must be provided.
* Time: the time of each event must be available to the high level
program in a usable form. srfi-18?
* HIgh level event handlers. a Scheme closure may be assigned to
handle any event or bundle of events the program is interested in.
* High level containers: there must be a way of expressing a
hierarchical relationship between widgets. This should be coupled to
the container mechanism of the underlying GUI where possible, but
should not depend on such a mechanism existing.
* Configuration: the application must be reasonably configurable at
run time. The native configuration tools should *usually* take
precedence, and the high level GUI works within the constraints set by
those tools. The program *may* be permitted to break this.
Desirables:
* Queues: we need a standard for queues. whether based on Chicken,
Scheme48, Gauche or whatever. High level event queues would be based
on that standard.