While it may be rather difficult, and possibly even impracticable, to produce a general super GUI, it should be possible for all Chicken GUI eggs to provide GUI features in a uniform way.
To show the kind of thing I'm thinking of, I'll give some examples, graded by level of complexity. It isn't intended to be a definitive list, only an illustration of the kind of interaction that would make Chicken useful for basic scripting on a GUI-based system. The functions would enable simple interactive Scheme programs to make use of available facilities in any available graphical user interface. I would also suggest that these features could be provided by default on any chicken build where the underlying operating system supports a GUI that is known at build time. Level 0: These basic functions are to be defined by any GUI egg compliant with this suggestion. The egg must register the feature 'gui-0, so that programmers can use cond-expand and default to non-GUI interaction where the feature is not provided. Function: (confirmation-dialog MESSAGE) Displays a message string and accepts a confirmation or cancellation. It returns #t if the user confirms (eg: clicks an OK button) and #f if he cancels (eg: clicks a Cancel button). The appearance and precise behavior of the widget is to be left to the implementor, and should follow the conventions of the underlying GUI where possible. It is an error to provide a non-string MESSAGE or one consisting of the empty string, or one that is longer than 256 characters. Function: (string-request MESSAGE [DEFAULT [MAX-CHARACTERS]] ) Displays a message string and accepts a string which is the return value of the function. If a default is given, the message-string widget is preloaded with that string value, otherwise it is initially empty. If no MAX-CHARACTERS value is given, a sensible default may be chosen, but at least 512 characters must be accepted. There should be a way for the user to cancel the request, in which case the return value is #f. It is an error to provide a non-string MESSAGE or one consisting of the empty string, or one that is longer than 256 characters. It is an error to provide a non-numeric MAX-CHARACTERS, or a value less than 1 or greater than the implementation maximum (which must be at least 512 characters). Level 1: These more complex functions are to be defined by some GUI eggs compliant with this suggestion. The egg must register the feature 'gui-1, so that programmers can use cond-expand and default to non-GUI interaction where the feature is not provided. Function: (text-edit MESSAGE LIST) Accepts a list of strings which are displayed and may be edited by the user. The facilities must permit deletion and insertion of the whole text, whole lines, and arbitrary regions of text including single characters. Other features of the underlying GUI may be supported at the discretion of the implementor. There must be a facility for the user to terminate the edit at any time, in which case the function returns #t if there has been no change, or else a new list of strings representing the edit contents. There must be a facility for the user to cancel the edit at any time, in which case the function returns #f. It is an error to provide a non-list, or a list containing anything other than strings. The null list may be provided, in which case the initial contents of the edit widget will be blank. MESSAGE is mandatory and is subject to the same constraints as in the gui-0 functions. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
