Erick Gallesio <eg_at_unice.fr> writes:
> BTW, there are far less developers for STk than for these toolkits, I
> don't know why and it is not that I only want a cathedral development
> style for STk. This is tsimply that nobody else seems to be interested
> to co-maintain it ;-)
>
>
> > My impression is that STk has a relatively low profile --- you don't
> > even find a mension of it on the Tcl/Tk web pages (where PerlTk and
> > Python are).
> >
>
> My interpretation is that the rms Tcl-war which arose 5 years ago
> explains that. Guile is also connected to Tk and I suppose that it is
> not mentioned too ;-)
I would like to make a potentially controversial suggestion. Perhaps
guile could become the base for STk. I know some guile/stk work has
gone on already, and that STk and bigloo are getting closer together,
also.
I love to use STk, but I tend to use guile for it's ease of embedding.
Then I can't use STk. The Tk binding for guile stinks, compared to
STk. If I could have STk in guile, I would stand up and do a Snoopy
dance, I'd be so happy. I'm quite familiar with guile, so I could be
a resource for answering questions about how to get something working
that is currently implemented in the STk interpreter.
Some of the work is already done; there is a significant piece of
STklos implemented and downloadable from
ftp://www.read-bean.com/pub/guile.
Using guile has it's own set of issues, but there are some
considerable advantages, too. For one thing, there is a dedicated
maintainer for the interpreter itself. Also, there is a growing
developer community. There is a C compiler for Scheme code in guile
(not as nice as bigloo, I agree), too.
-russ
--
There is always free cheese in a mousetrap.
Received on Sat Oct 03 1998 - 22:04:42 CEST