STk 3.0 b1 is on kaolin

From: Erick Gallesio <>
Date: Sat, 07 Oct 1995 13:31:15 +0000

Hereafter is the README file for 3.0, which is included in the STk-3.0b1

It as only been tested on Linux and SunOS.
Please tell me if you have problem with it.

Have fun
                -- Erick


This is the first beta release (b1) of STk 3.0

The main difference with previous release relies principally on the Tk
support. STk 3.0 integrates Tk4.0 (the two patches for Tk will be
applied for next beta release).

STk 3.0 tries to propose a more "schemish" view of Tk. Normally you
should not see anymore all the weird details of communicating with
Tk. Furthermore, Tk returns value which are true Scheme object (e.g.
booleans are no more 0 or 1 but real #t or #f, callbacks are true
closures...). Tk is modified in numerous places to achieve this. I
think (hope) that all this places have already been modified. If you
see that some result is not what one should expect with Scheme,
please drop me a mail so I can adapt it

Since this version is a beta release a lot of stuff is not as it
should be: some demos have not bee adapted for Tk4.0 (4.0 is not
compatible with 3.6, and a lot of things have been changed in STk
which are not always compatible with 2.2 -- see below for details).
The more important thing which must be done consists to adapt the
documentation. This will be done for the "official" release of 3.0.

One important novelty for 3.0 is the the support for a subset of HTML
(have a look to Demos/hbrowse for a simple HTML browser). Documentation
of some Tk commands is already available in HTML. Just type
        (help "button")
to browse the button page. Ommiting the name of the comand to document
brings you to the documentation toplevel.

The widget demo has been rewritten completly in STklos. I hope that it
will help you until the STklos documentation will be
finished. (Volunteers for documentation are always really welcome)

STk-3.0b1 is available at the following URL

    I have not corrected most of the bugs signalled to the mailing-list or
    that you have sent to me in this release. I apologize for this but
    have concentrated my efforts on the new Tk support since 2.2 and I
    have tried to release it as soon as possible. I plan to fix all (most
    of) those bugs, and some interesting suggestions made in the mailing
    list, for the next beta release of STk.

Hereafter are some notes which explain the main differences between 3.0 and 2.2

* All command which create a widget return now a Tk-command (rather than a
whose value is a Tk-command)

* You can use closures in commands and binding associated to a widget.
  In fact, you MUST use closures rather than strings. To make transition
  old command forms are always acceptated but are strongly DISCOURAGED
  (they will probably not be supported in the future). BINDINGS SCRIPTS CANNOT
  Here are two examples:
        (button '.b :command (lambda () (display "Hi\n")))
        (bind .b :command (lambda (x y)
                             (format #t "mouse position (~A,~A)\n" x y)))

  As you can see bindings closures can have parameters. Thoses parameters are
  one character identifiers (with the same conventions than the Tcl % char). If
  parameters are specified, they will be passed to the closure when the script
  is fired. Note that there is no more special meaning to the '%' character.
  the :command :xscrollcommand ... accept all a closure as value. This closure
  must be a thunk.

* All Tk-commands which return 0 or 1 return a boolean value now. You must
pass a
 boolean value to this options (i.e. here the exact value is tested, this
 us to use the old convention such as 0, off, no for false and 1, on or yes
 for true. In counterpart, we have not the Schemish convention that every value
 other than #f is is considered as true). Should I change this?

* hexadecimal values use the "#x" Scheme notation instead of the C-like "0x"
  As a result, the value will be converted in decimal when read back by the
  layer (rather than a symbol of the form 0x123).
* The new Tk option :takefocus can be a closure or a boolean. This closure
  should take an argument and should always return a boolean which indicates
  if the widget take the focus or not. The given argument is the widget which
  is proposed to take focus. If the :takefocus is a boolean, its value
  if the widget take the focus or not. For instance we can write
        (button '.b :takefocus (lambda (w)
                                  (format #t "~S take the focus\n" w)
                                  ;; Return #t to effectively take it

* result of Tk-command widget constructor (button, entry, menu, ...)
  returns the widget rather than its name. For instance
        (button '.b)
  returns #[Tk-command .b] rather than .b

* winfo has been largely modified to return widget rather than their
name. For instance, (widget 'children) will return a list of tk-command rather
than a list of symbols.

* modification in winfo: a lot of sub-option result have been "stringified"

* Canvases: tags are always Scheme lists

* Canvases: arrowshape is always a Scheme list

* Texts: index can be a cons. You can do now
        (.t 'insert (cons 1 "end") "ABC")

* Texts: Qurying the value of an index always return a cons.
        (.t 'index (cons 1 "end")) ==> (1 . 3)

* Texts: When searching a string in the text widget (new 'search
option) the result is #f if the string is not found

* Texts: (.t 'window 'names) returns a list of tk-command rather than
a list of symbols

* Selection not always returns a string as before.

* Selection: (selection 'own) returns #f if no window has the selection

* grab: return #f if no one grab the screen

* focus: returns #f if no window has the focus

* menubuttons: the -menu returns a Tk-command rather than a string. If no menu
 associated to it, the value is #f

                -- Erick
Received on Sat Oct 07 1995 - 13:31:16 CET

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST