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. * Time: the external form of this should follow IETF RFC 3339 and any superseding standard. * Foreign function interface. A reasonably abstract foreign function interface should be provided to enable drivers to be ported from one Scheme implementation to another. Adherence to that ffi should not be mandatory. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users