Xref: utzoo comp.windows.news:1819 comp.windows.x:16641
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!tub!net
From: net@tub.UUCP (Oliver Laumann)
Newsgroups: comp.windows.news,comp.windows.x
Subject: Re: Toolkits, toolkits, toolkits ...
Message-ID: <1135@tub.UUCP>
Date: 8 Jan 90 14:13:18 GMT
References: <7391@ficc.uu.net> <634@s5.Morgan.COM> <4572@hplabsz.HPL.HP.COM> <1132@tub.UUCP> <4585@hplabsz.HPL.HP.COM>
Reply-To: net@tub.UUCP (Oliver Laumann)
Followup-To: comp.windows.x
Organization: Technical University of Berlin, Germany
Lines: 27

In article <4585@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:
> 
> The Elk approach is more of a 1-to-1 correspondence to the Xtoolkit
> intrinsics calls, and is similar to my initial proof-of-concept "alpha"
> WINTERP that I hacked together out of ELI and the HP Xwidgets about a year
> ago. I found my "alpha" approach to be workable, but still a bit too
> verbose.

Since we are using Elk-Scheme as the extension language for a `real'
software package (an ODA-based document processing system), we do need to
be able to access the full power of the X toolkit, for instance, our
application must be able to open more than one display (for shared editing
of a document).

Of course, funtionality like opening a display and creating an
application context (the things that you called `noise') can be hidden
in an additional `layer' if desired; building abstractions is one of
the things that can be done in Scheme quite elegantly (which is one
reason why we think that Scheme is better suited as a general extension
language than, for instance, Xlisp).

[Since this has no longer anything to do with NeWS, I have directed
follow-ups to comp.windows.x]

Regards,
--
Oliver Laumann              net@TUB.BITNET              net@tub.UUCP