chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Simple GUI features


From: Tony Sidaway
Subject: [Chicken-users] Simple GUI features
Date: Thu, 15 Feb 2007 17:56:29 +0000

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]